NULL Pointer Exploit Excites Researchers 327
Da Massive writes "Mark Dowd's paper "Application-Specific Attacks: Leveraging the ActionScript Virtual Machine" has alarmed researchers. It points out techniques that promise to open up a class of exploits and vulnerability research previously thought to be prohibitively difficult. Already, the small but growing group of Information Security experts who have had the chance to read and digest the contents of the paper are expressing an excited concern depending on how they are interpreting it. While the Flash vulnerability described in the paper[PDF] has been patched by Adobe, the presentation of a reliable exploit for NULL pointer dereferencing has the researchers who have read the paper fascinated. Thomas Ptacek has an explanation of Dowd's work, and Nathan McFeters at ZDNet is 'stunned by the technical details.'"
Binary blobs (Score:5, Insightful)
Re:Why the java icon? (Score:3, Insightful)
Re:fubar (Score:3, Insightful)
Re:hmm. (Score:2, Insightful)
Re:boring? (Score:5, Insightful)
Actually, it is a big deal, as you'd know if you'd read the article(s). But you're too lazy for that, so here's the short summary:
Lots of interesting (and important) security problems revolve around figuring out a way to take an error in a program, and turn it into a way to have that program execute arbitrary code of your choice. Traditionally, NULL pointer exceptions have not been fruitful ground for this because, well, a NULL pointer is NULL -- there's nothing on the other end of the pointer for the unsuspecting program to read or execute, so it simply crashes. And merely crashing the program isn't really all that interesting, since at best it lets you execute a denial-of-service. But this guy (Dowd) found what would have been a run-of-the-mill NULL pointer exception in Flash and parlayed it into full-scale arbitrary code execution through a series of fairly impressive tricks. You really should go read Ptacek's summary, because it has all the gory details and will, if nothing else, make you realize what an amazing hack this is.
Re:Why the java icon? (Score:5, Insightful)
Re:Always check your return values! (Score:5, Insightful)
The only way I've seen to get it to consistently fail is not on low memory but by asking for ludicrous amounts like 4GB at once on a 32bit system. Try it - get your system into a low memory condition and execute a few mallocs.. they don't fail - the OS merely continues to increase virtual memory and swap more and more.
Re:The crux of the exploit: (Score:3, Insightful)
If you think Flash sucks now, wait until it is written in 100% Java.
Re:The crux of the exploit: (Score:5, Insightful)
You do understand that all those nasty loosely-typed pointer-based exploits you and others disdain in C, exist because C nicely mirrors how the actual hardware handles similar concepts?
If failure of allocation threw an exception, instead of just returning null, there would be no problem.
And if programmers would check that the allocation succeeded, we would also have no problem.
In your hypothetical "safe" language (C#, for example), I can't count how many times I've seen system calls wrapped in a try/catch to hide the exception, then carry on pretending the call worked just fine. Guess what? SAME DAMNED PROBLEM!
Don't blame the pipe-wrench for making a poor hammer. Blame the craftsman too lazy to find a hammer.
Re:Big deal (Score:5, Insightful)
Because it can probably be made to work cross-version, cross-platform and cross-architecture?
Because everyone has Flash installed?
Because it opens up a whole class of common bugs previously thought to be unexploitable?
Because the way he does it is nothing short of godlike?
This is HUGE.
Re:The crux of the exploit: (Score:5, Insightful)
Re:The crux of the exploit: (Score:1, Insightful)
Wait, what was this article about again?
Re:fubar (Score:2, Insightful)
While you can determine this easily for any given architecture/Linux distro pair, determining what particular distro and architecture are present from remote is problematic at best.
Furthermore, if I'm not mistaken, there are certain SELinux rules you can use to prevent shell scripts from doing nasty things.
Re:hmm. (Score:3, Insightful)
If however it can run arbitary x86 code directly all bets are off and operating system security is basically non-existent except at the hardware level
Re:The crux of the exploit: (Score:3, Insightful)
what should be banned are those useless coders who think that a language should do everything for you, thus making you lazy and bloated like your code.
remember: you are in control of the machine, not the other way around.
Re:Always check your return values! (Score:4, Insightful)
Re:fubar (Score:1, Insightful)
a) if the wheel falls off at just the right time, your car can swerve into oncoming traffic and kill an entire bus full of precious children,
or
b) wheels coming off cars are a generally bad thing.
?
Rephrasing the question: do we fix a NULL pointer problems because
1) some clever guy with time to waste might be able to figure out how to convert the problem into the erroneous detonation of a nuclear warhead,
or,
2) because it is just an easy-to-fix stupid bug, and bugs are just bad in general?
My assessment of this situation is that far too much analysis was undertaken. Rather than piecing together some careful exploit, this guy could have spent the time looking for other bugs in the code instead. NULL pointer dereferences are among the easiest bugs to find and fix. Report it, fix it, and move on. Filling the net with manifest useless fear while you try and prove your cleverness accomplishes
Re:fubar (Score:3, Insightful)
Re:Big deal (Score:5, Insightful)
It's news because it's a general method for code execution from a common class of NULL pointer dereferences. He turned something that most people consider a crash bug into a code execution bug. Here's a simpler example from Dowd's blog: http://taossa.com/index.php/2007/04/15/bored-games/ [taossa.com]
The other reason why it's news is that his method for exploiting Flash in this case is technically brilliant. I can understand if you don't appreciate it, but any security people out there are just overwhelmed.
Re:The crux of the exploit: (Score:0, Insightful)
A great many people may consider that Flash suck for reasons others than its graphical performances. In other words Flash may be using the snappiest/smoothest/nices fonts/graphics ever, it could still be considered by a great many to be very sucky.
On your comment about Java... The JVM has proved that everything written in pure Java is 100% immune to buffer overflow/overruns. You simply are NOT going to see a 'null exploit' for a Java JVM. This is not just a happy thing: it is a fact that can be provably demonstrated. You simply are NOT breaking out of Java-written code. Oh, of course there have been a few exploits here and there... Notably one on Linux where a malicious user could escape the JVM by exploiting the C-written zlib (how fun isn't it? good old C exploits).
I seriously wish many of these libs were 100% Java and many more userland programs (everything not related to the kernel's internal) were written in Java.
Give me a Web broser 100% Java, give me flash 100% Java, give me media players 100% Java, give me games 100% Java.
Oh wait, past century's Java troll modded +5 insightful "Java is slow" ?
We just finished moving a nightly monte-carlo simulation app to price options in a major bank from C++ to Java. Perfs ? Identical.
But, yeah, Java suck, Java is slow, etc.
Seriously dude, wake up : Java is in your pocket, you can't do a non-cash payment without having Java involved in a process, you can't use the Internet without going to Java-backed webservers, Java is part of the Bluray specs, there are entire countries where people's ID cards are Java SmartCards. Google, eBay, FedEx: they all realized the value of the JVM. I code my apps and they work on any Un*x, Windows and OS X machines. Why the heck should I bother with *anything* OS specific unless I'm a kernel hacker ? Because I'm living in a cave since 30 years ?
Oh, it's not that the language is great (it's not). But the JVM is the best thing that happened to the IT world in decades: the Real World [TM] got it and the JVM's success is 100% justified.
Java makes the real world go round and you better adapt and accept it, for the real world won't adapt to your bogus view about Java.
Re:The crux of the exploit: (Score:2, Insightful)
Yeah, which is why you *don't catch exceptions you can't recover from*. It's a basic design tenant, and it's *easier* to do than fucking it up by incorrectly handling the error. Basically, in a language like C, you have two options:
1) Check for the error and handle it, possibly incorrectly, leading to the problem you describe.
2) Ignore the error, and your program could misbehave.
An exception-based language gives you these options:
1) Catch the error and handle it, possibly incorrectly, leading to the problem you describe.
2) Ignore the error, and the program violently terminates.
Gee, which one do you think is better from a security standpoint?
Nope, sorry buddy, but *any* language that uses exceptions as the model for error indication will be superior, as far as security goes, to a language like C. The real problem with the GP is that that also includes C++ (which, at least in a decent compiler, throws an exception if new fails to allocate a chunk of memory).
Re:The crux of the exploit: (Score:3, Insightful)
making programming simpler only means that simpler coders will be coding.
Re:The Art of Software Security Assessment (Score:3, Insightful)
The books that I keep around for a long time are the ones that really cover the essentials. I put this book in that category because it explains vulnerabilities more clearly and thoroughly than anything else out there. And it lays out all the process and tricks for finding security bugs. That's the kind of stuff that will be relevant for years.
Re:fubar (Score:3, Insightful)
Debugging is generally handled in a triage fashion. The first bugs to fix are easily exploitable remote exploits that allow arbitrary code execution with elevated privileges. Then come those that allow easy remote exploitation and arbitrary code execution at the user's restricted level. It goes on like that all the way down to a bug equivalent to "sometimes on platform X the last character of output sometimes is an extra newline that gets appended which is unnecessary".
If you have the time to make sure every piece of software you write is entirely and certifiably bug free, then that's great. Somehow, though, I imagine maintenance programming for the rest of us will probably still be prioritized based on severity.
Re:The crux of the exploit: (Score:3, Insightful)
I thought this was going to be something interesting like the 0 page exploit described in Bach's Unix System V Internals book where on certain kinds of hardware, it was possible to read NULL and near NULL pointers without the machine faulting allowing access to kernel data (which worked on my M68K Unix System V box at the time). Instead it's just a sloppily written byte code interpreter bug.
Re: are executions necessary? (Score:3, Insightful)
Most of the patches I see popping up in Ubuntu's update notifier seem to involve buffer overflows. Now there is this exploit because someone didn't check a pointer (failed malloc()/new/etc?).
When I taught CS, back when dinosaurs ruled the earth, I would have given a homework assignment with anything like that a D or an F.
I mean WTF, fast forward a few eons and people are still writing code like this??? What do we have to do - shoot them???
A programmer not checking for a null pointer return or a buffer overflow is the equivalent of... geez, I don't know... a surgeon forgetting to wash his hands before operating?