Archive for July, 2007
Dave G. | July 30th, 2007 | Filed Under: This Old Vulnerability
Welcome to the pre-blackhat edition of This Old Vulnerability. iDefense recently put out an advisory on AIX’s ftp client. Let’s start out with a joke:
Knock Knock!
Who’s There?
AIX’s Team.
AIX’s Team Who?
AIX’s Team, who, besides you, ships ftp clients setuid root in 2007?
Yeah. I don’t get it either. Now you might think that is the most humorous thing I can say about AIX’s setuid root ftp client. Sadly, you are mistaken. This ftp client has had a history of security vulnerabilities. Let’s talk about the most recent iDefense one and work our way back.
This setuid-root ftp client has a buffer overflow in it. Not just a buffer overflow, but a stack-based buffer overflow (I could swear it’s 2007). Not just a stack-based buffer overflow, but the most simple kind, an unbounded read from user input. (I don’t remember 2006 very well, but all of my computers say 2007) Even more entertaining, it is due to calls to gets(). (Is this the Morris worm? Am I trapped inside of 1987?)
To understand this further, I caught up with one of the world’s foremost authority on gets():
Q: gcc What do you think of the gets() function?
A: gcc: What: No such file or directory
gcc: do: No such file or directory
gcc: you: No such file or directory
gcc: think: No such file or directory
gcc: of: No such file or directory
gcc: the: No such file or directory
gcc: gets(): No such file or directory
gcc: function?: No such file or directory
gcc: no input files
Q: Oh, sorry, my bad. I will submit my question in the form of C code.
gcc -o gets-question gets-question.c
A:
/tmp/ccPW3krf.o: In function ‘main’:
/tmp/ccPW3krf.o(.text+0x24): the ‘gets’ function is dangerous and should not be used.
Q: Thank you for your time.
So, to recap, in the year 2007, there is a commercial operating system shipping a setuid-root ftp client with calls to gets() in it.
Now, this story could end here. Old forgotten code that no one has looked at in awhile. However, I distinctly remembered that there has been a history of vulnerabilities in this superfluously setuid root code. Almost as good as the sendmail debug vulnerabilities, the archive footage for this vulnerability shows:
AIX ftp tftp and utftp Core Dump Vulnerability
Some versions of ftpd, tftpd, and utftpd under AIX use the gets() system call to gather information from standard input (STDIN). The gets() system call has no means to denote size of the string it is handling and allows for an infinite amount of data to be passed into it. The problem lies in that the code in ftpd tftpd and utftpd which takes data from the gets() call places it in a fixed buffer. This buffer can be overflown resulting in the applications dumping core. Because these programs are run as root, the core images may contain critical root owned pieces of memory, such as user names and passwords.
The description is totally confusing at first. The title says it’s the clients that have the vulnerabilties, but the description says it’s the servers. Which are we to believe? I believe it to be the clients. I believe this for two reasons.
The title for the vulnerability can be found in other documents on the Internet.
There is no evidence that AIX shipped with a utftpd. But you can find man pages for a utftp with is a version of tftp for use in pipes.
I wonder if these are the same gets() calls from the iDefense advisory. I really wonder how they fixed the original vulnerabilities (rlimits on coredumps?). I really really wonder why this all has to be setuid…
Here are some other vulnerabilities that have impacted their ftp client in the past:
IX70885 SECURITY: FTP CLIENT INTERPRETS SERVER PROVIDED FILENAMES. The ftp client can be tricked into running arbitrary commands supplied by the remote server. When the remote file begins with a pipe symbol, the ftp client will process the contents of the remote file as a shell script.
IX85556 SECURITY: BUFFER OVERFLOW IN FTP CLIENT. When parsing a 227 message, the ftp client may generate a segmentation violation and core dump. (and by segmentation violation and dump core, we mean run attacker supplied machine code as root).
IY13781 SECURITY: FORMAT STRING VULNERABILITY IN FTP CLIENT. The ftp client shipped with AIX version 4.3.X contains a format string buffer overflow in the quote command. Since the ftp client is setuid root, this allows a local attacker to gain root privileges.
ftp> !/bin/sh (*)
(*) I really remember this being a vulnerability, but can’t find confirmation. It is possible that I have implicated ftp in tprof’s crime.
7 Comments
Thomas Ptacek | July 25th, 2007 | Filed Under: Gatherings, Uncategorized
Atlanta is an excellent security city, between ISS, Georgia Tech, and the constellation of tiny security startups twinkling in and out of existence. And, like Chicago in February, you can’t really be outdoors anyways right now (it’s like 120 degrees with 100% humidity), so you might as well spend the evening at the inaugural HotSec meeting. It’s at the Brick Store Pub near Decatur (wherever that is), starting at 6PM.
Phoenix might also be an excellent security city, but I’ll never know, because I’m to terrified that I’ll burst into flames to ever leave the airport. Unfortunately, SunSec is not in the airport; it’s in Scottsdale. It’s tomorrow. Follow the link for more details!
In both cases, you do not need to RSVP, and you do not need to “join up”; that’s the whole point of the meetup. Just show up, drink beer, and meet the local security people in your area.
No Comments
Dave G. | July 24th, 2007 | Filed Under: Industry Punditry
The announcement for the Pwnie awards fired across the DailyDave yesterday.
The quick description is:
The Pwnie Awards are an annual award ceremony celebrating the achivements and failures of security researchers and the security community.
It will feature awards such as:
- Pwnie for Best Server-Side Bug
- Pwnie for Best Client-Side Bug
- Pwnie for Mass 0wnage
- Pwnie for Most Innovative Research
- Pwnie for Lamest Vendor Response
- Pwnie for Most Overhyped Bug
To my knowledge, this is the first attempt for the vulnerability research industry to acknowledge and recognize the innovative work of out peers. This is important. For a discipline that has existed for 20+ years (i can already sense an email from bell labs telling me its closer to 40 years), it seems crazy to me that we haven’t done this sooner. Yes, calling it the Pwnies is a silly. Yes, some people are going to disagree with having a sense of humor about this. This is a great starting point.
That’s why when Mark Dowd, Alex Sotirov and Halvar Flake asked me to be a judge several months ago, I agreed. I am sure this will be anything but a smooth process, but if you perform vulnerability research, get involved. Email us. Most importantly, nominate your peers (ok, most likely yourself).
I am not the only person that thought this was important. The judges are currently comprised of:
Mark Dowd
Dino Dai Zovi
HD Moore
Dave Aitel
Halvar Flake
Alexander Sotirov
and
Which if this were a film festival would look something like:
Quentin Tarantino
Steven Spielberg
Martin Scorcese
Robert Altman
Paul Thomas Anderson
Francis Ford Coppola
and
5 Comments
Thomas Ptacek | July 19th, 2007 | Filed Under: Gatherings, Uncategorized
0000 43484953 45432031 32206973 20544f4e |CHISEC 12 is TON|
0010 49474854 2c206174 20486f75 6c696861 |IGHT, at Houliha|
0020 6e277320 0a6f6e20 5761636b 65722c20 |n's .on Wacker, |
0030 646f776e 746f776e 2c207768 65726520 |downtown, where |
0040 5761636b 65722061 6e640a4d 69636869 |Wacker and.Michi|
0050 67616e20 696e7465 72736563 74206174 |gan intersect at|
0060 20746865 20726976 65722e20 57650a73 | the river. We.s|
0070 74617274 20617420 372c2077 6520656e |tart at 7, we en|
0080 64206172 6f756e64 2031302e 20596f75 |d around 10. You|
0090 200a646f 206e6f74 206e6565 6420746f | .do not need to|
00a0 20525356 502e0a0a | RSVP...|
00a8
More details here. See you there.
No Comments
Dave G. | July 18th, 2007 | Filed Under: Apple
InfoSecSellout points us to new mDNSResponder flaw that is, as the vuln reasearch community likes to say, wormable. In fact, InfoSecSellout claims to have done just that.
Which, of course, got the folks at McAfee all riled up. They also have older version of InfoSecSellout’s post. They end their post with:
This story prove both things: the first is that Macintosh with Intel is an interesting target. Real outbreaks are more than ever possible. The second is that the lure of money motivates many people more or less scrupulous. It is another cause for concern.
The PowerPC vs. Intel debate is pretty useless. If you can write exploits on x86, ramping up on what you need to know to exploit vulns on PowerPC is trivial. At least, it was when I did it. It isn’t to say that there aren’t any differences, just that they don’t amount to much from a security perspective.
Of course, Intel vs. PPC is neither here nor there. This post is about mDNSResponder, otherwise known as the primary client -> server attack surface on Mac OS X. The firewall lets mDNS traffic through, and while it is unclear whether or not you can reach mDNS if you aren’t on the local subnet, it’s bad either way.
My favorite part of the source code is LegacyNATTraversal.c. Even the name just speaks of potential problems. Legacy… mmm. NATTraversal… mmm.
Other fun parts:
Revision 1.14.2.1 2005/12/12 17:38:40 cheshire
Put buffer overflow bug 4151514 back in by order of Program CCC:
“Program CCC Denied. This change does not meet the criteria for Chardonnay.”
…
Revision 1.13 2005/09/07 18:23:05 ksekar
Off-by-one overflow in LegacyNATTraversal
…
Revision 1.9 2004/10/27 02:25:05 cheshire
Random memory smashing bug
Lots of uPNP/SOAP message handling. Plenty of unbounded memory copies, and oh yeah, a history of overflows and memory smashing bugs. If I were guessing where mDNSResponder is going to have bugs, it’s in here. But it is nothing more than a guess.
If you want to run mDNSResponder without using the LegacyNATTraversal code, which might have nothing to do with the aforementioned mDNS worm/vuln, apply this patch, provided by Dino Dai Zovi.
Standard disclaimers about this patch apply (including: may do nothing, may protection you form current/future vulns, may cause mDNSresponder to not work, may break support contracts). Also, this patch is unsupported, which is why I didn’t give step by step instructions on how to apply it. Did I mention that this might have nothing to do with InfoSecSellout’s vuln? And that it could break things? and that we aren’t going to support it?
14 Comments
Jeremy Rauch | July 17th, 2007 | Filed Under: Uncategorized
Hey. Whats up? In NYC? Busy doing anything from 6 until 9ish? No? Did you know NYSEC was tonight? Happens the 3rd Tuesday of every month, at Pound and Pence in the Financial District. Corner of Nassau and Liberty. You should come. We’ll probably be upstairs.
More details, if you need them, at http://www.sockpuppet.org/nysec.
1 Comment
Thomas Ptacek | July 16th, 2007 | Filed Under: Apple, Uncategorized
1 INT. MATASANO OFFICE - EVENING
Just days before Black Hat. THOMAS PTACEK sits, polishing up
Blue Pill detection code. Across the room, DAVID GOLDSMITH,
resplendent in purple smoking jacket.
THOMAS PTACEK
I love Apple's IOKit.
DAVID GOLDSMITH
Why?
THOMAS PTACEK
Because you can take a physical address,
like the high-performance event timers on the LPC bus, and wire them
into a userland process. The process can say, "put the HPET at
0x22220000". And it's like, one line of code!
DAVID GOLDSMITH
Yeah, this is what scares the shit out
of me about IOKit.
No Comments
Thomas Ptacek | July 12th, 2007 | Filed Under: New Findings, Uncategorized
Via Slashdot:
You’re a bad guy sharing a Linux server with a bunch of good
people. All of you are running processes and those processes share
access to the CPU by working in 10-100 millisecond time slices. This
is called multitasking.
You don’t want to share because you’re bad. So unlike the good people,
your processes:
Figure out how long a timeslice is in cycles
Sync themselves to the start of a clock tick with a
scheduling no-op nanosleep()
Execute for fewer instructions than is allocated to
a process time slice.
Yield back to the scheduler with another nanosleep().
The result, on many OSs, is that the scheduler basically doesn’t
“notice” you ran. You get an unfair share of scheduler resources, or
even monopolize the CPU.
Yawn.
A question: anyone researching attacks against hypervisor scheduling
algorithms? Nobody shares an OS kernel with other people anymore, but
in a few years everyone will share iron in side-by-side VMs. I mean,
apart from things like Linux KVM virtualization (which is just
processes, so is presumably affected somehow).
No Comments
Thomas Ptacek | July 12th, 2007 | Filed Under: New Findings, Uncategorized
[Update 7/12]
This post touched a nerve on Reddit. C++ programmers, unsurprisingly, have some issues with this post. Go read the Reddit comments; they’re excellent. And then vote my post up!
1.
Almost 10 years ago, during the dot-com bubble, I did what many
security pros before and after me did and “gave up on security” to “go
do something meaningful” [∗]. I was at Network Associates (after they
bought Secure Networks), and David Meltzer, my alter-ego at ISS,
recruited me into a startup along with Danny Dulai and Tim Newsham. We
wanted to build the chat system of the future, and we ended up with
application-layer multicast streaming media. In 1999. We were a bit
ahead of our time [∗∗].
This is good to know because it will help you avoid ever starting
a discussion with me about reliable multicast protocols (down with
forward error correction!) or source-specific multicast routing (down
with source-specific multicast routing!). But why I bring it up is, we
wrote it in C++. We wrote a lot of C++. A lot. We used ACE. Used ACE
before? You know how much C++ we were swimming in. A lot of
C++. Template-y, Boost-y, Alexandrescu-understandingy C++.
2.
Now this is a security blog, and so I’m supposed to be using this time
to make a point about security, and that point is this: the notion
that C++ is a more secure language than C is a myth. C++ gives you a
dynamically-resizeable string class, which makes it less likely that
you are going to write the splitvt overflow. But it also gives you a
dozen new features which, if you use them wrong, segfault your
program.
3.
Take exceptions. C++ has built-in support for exceptions; when
something horrible happens, you “throw” a variable that any stack
frame up the call chain can “catch”. This is better than returning a
cryptic error code, because you can’t forget to check it.
But. When you throw an exception, you effectively “abort” your current
function, and all the functions in the call chain up to the point
where the exception was caught. If any of these functions aren’t
written to anticipate getting preemptively aborted, and hold on to a
pointer or a chunk of memory, you’ve got a memory lifecycle bug.
This problem is well known to the C++ community. Herb Sutter wrote a
famous article about it, which invented the notion of “exception-safe”
C++ programming. Joel Spolsky wrote a JoelOnSoftware about it. There’s a
debate about whether C++ exceptions are evil.
But it’s not well known problem to the security community. A year or
so ago, Mark Dowd found yet another Sendmail vulnerability. Sendmail
is written in C, not C++, but it uses Unix signals and “longjmp” to
emulate C++ exceptions, and (it’s Sendmail, after all) isn’t written
exception-safe. You can trigger a timeout exception, and Sendmail will
retain an invalid pointer into the stack that it would have cleared
out if the exception hadn’t occurred. That pointer can be used to
scribble over stack frames.
Any time you have a language feature, and you have to think about
writing code to be “that-language-feature-safe”, you have a security
problem. Because that feature is creating bug classes. Bug classes are
bad. Splitvt? That’s a bug. Stack overflows? Bug class. Stack
overflows cost the industry over $700MM. Exception-safety problems?
Bug class. One that C++ introduces.
4.
Want another example? Destructors. Mark Dowd and John McDonald wrote a
blog post about it a few months back. Do you audit code at your job?
It’s one of the top #10 most valuable blog posts of the year. Long
story short? If you call “delete[]” instead of “delete” —- which is
an exceedingly common C++ error —- you’ve introduced a potential
vulnerability. Like integer overflows, a bug class.
5.
Here’s another example: the STL. STL (or, more properly, the Standard
C++ Library) is the collection of container classes C++ provides. In
C, if you want a hash table, you have to implement it yourself. In C++
—- bad example. But if you want a red-black tree with the same API as
a hash table, it’s provided for you. Also linked lists, resizeable
arrays, and something called a dequeue (prounced “woon”). The STL is
one of the great features of C++.
It’s also a reliability disaster. Here’s why: STL containers try to
hide pointers from you. Instead of pointers, you get “iterators”,
which are objects with a variety of interesting methods and generic
functions that operate on them and all sorts of other fancy gunk and
at the end of the day it’s all just 1500 lines of C++ template code
wrapping: a pointer.
STL tries to avoid the most common pointer bugs, like walking off the
end of an array into bad memory. But some bugs can’t be avoided. So
for instance: if you modify an STL map (which is a red-black tree) [∗∗∗] vector or dequeue,
you invalidate all your outstanding iterators. Modifying a
red-black
tree container potentially repositions the nodes they pointed to, and all that
fancy OOP gunk aside, iterators are just pointers, not magic. If you
hold references to those invalid iterators, they now point to invalid
addresses.
This is an absurdly common problem. I’m an OK developer, if I do say
so myself, but Danny Dulai, Kneel Fachan, and Tim Newsham are just
fucking insanely talented developers and they ran into these
problems, just like me.
And again, this problem is well known in C++-world (there’s a whole
very excellent book about it). But it’s not well known in the security community.
And when you screw it up, it’s potentially exploitable.
6.
C++ gives you a resizeable string, so you won’t write splitvt. But in
2007, code vulnerabilities don’t look like splitvt anymore,
ever. We’ve moved on, through off-by-one errors into integer overflows
and now uninitialized variables. On balance, the bug classes
C++ introduces are way scarier than the ones it takes off the table.
So, to kick off our series of posts about which Black Hat talks you
should be going to this year, I’m going to recommend this one. Mark
Dowd and John McDonald, on stage, talking about the ways C++ screws
software security that you hadn’t thought of before. “Recommend” is an
understatement. If you get paid to find vulnerabilities in code, this
is the most valuable talk at the conference this year.
See you there!
[∗] For the most recent example of this phenomenon, see Dug Song.
[∗∗] This is marketing-speak for “wrong”; you can say the same thing
for a batter’s swing when he takes a strike.
[∗∗∗] Deleting map nodes invalidates some iterators in a map, but adding nodes doesn’t. Breathing on a dequeue invalidates iterators.
31 Comments
Dave G. | July 11th, 2007 | Filed Under: Industry Punditry
Mike Murray riffed off of my post on WabiSabiLabi. He talks about how if you can buy a vulnerability cheap enough, you wouldn’t bother researching the vulnerability, because it is likely to cost more to find it yourself.
Which is a valid point. However, my post was less about whether or not it is worth the money and more about the fact that by posting the description of (somewhere between some and many) vulnerabilities, you lower the value of the vulnerability. For example, someone bid on the vulnerability mentioned in my post “Squirrelmail GPG Plugin Command Execution”.
In the comments of that post, Stefan Esser and others found several potential vulnerabilities. Maybe one of the ones mentioned is the bug in question. According to the website, two people have already bid on it. When they bid, it might have been worth the money. At this point, they might have bought a vulnerability that is patched in the latest version and is publicly known about. If that is the case, they might have made a different purchasing decision if they had the knowledge that this vulnerability would be discovered and fixed prior to the release (*).
Presumably only one person is going to be able to buy a given vulnerability. If multiple people bid, the loser may just decide that it is worth finding. And depending on if they can find it quick enough, the value of that vulnerability could go down significantly (even to zero), for the entity who purchased it.
(*) Who is to say that the vulnerability for sale is the one of the vulnerabilities identified by our readers.
5 Comments
