Slashdot Mirror
NULL Pointer Exploit Excites Researchers
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.'"
Some years ago I had many binary proprietary blobs on my computer: SUN Java browser plugin (now OSS), Adobe Acrobat (don't need it any more, OSS alternatives are equal now), nVidia driver (still needed but solution is on the way -> looking forward to switch to ATI as soon as GPL drivers get there), MS media codecs (don't need it any more, Flash ate MS' streaming video pie). Now, only Flash player remains that I don't see replacement in OSS world in foreseeable future. Add to it security concerns, 64-bit version and it clearly becomes major PITA of Linux desktop users. Doesn't look it will change any time soon.
839*929
I was wondering the same thing with the Java tag. My thought is the editors are actually ignorant and biased.
The NX bit doesn't get rid of the problem entirely, though. To use this example, it sounds like an exploit can be written pretty much entirely in ActionScript bytecode. Also, just because the stack is non-executable, what's to stop me from replacing the return address to point at, say, libc's system(), placing a nasty shell script on the stack?
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.
Probably because they see JavaScript, bytecode and virtual machine all in the same sentence. Put two and two together and you end up with five.
On a modern OS you have to work hard to make malloc fail. OSs will grant memory requests far above the amount of physical memory, and will even overcommit the virtual memory on the theory that you're not going to use all of it anyway.
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.
So you would ban knives from the kitchen because they are sharp and can cut you?
If you think Flash sucks now, wait until it is written in 100% Java.
Assuming that Flash is made in C or C++, here is another very vivid example of why these languages should be banned.
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.
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.
The kitchen? No. The Nursery? Might be a good idea.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
My blog
The difference is that in Linux the browser runs as you and so can only affect your own files ... (Which you have backed up?) On Windows the browser runs as an elevated user and so can affect much more ...
....
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
Puteulanus fenestra mortis
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.
The reason girls and Windows users don't understand UNIX is because all the documentation is in Man files.
You have to have contiguous sections of address space large enough for the allocation. If you're on Windows, and you've already allocated, say, a gigabyte of heap space, plus whatever is taken up by your code, stack and loaded libraries, then even a relatively small request might end up failing, even if there is enough memory available. There is just no free chunk large enough to satisfy it. In fact, on a 32-bit system, I can say with 95% confidence that you could never allocate, say, 1GB in a single allocation and have it succeed. There are probably smaller numbers that work here as well.
You're aware this site is News for Nerds, right? If this sort of thing is boring to you, maybe you're on the wrong site.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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/
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.
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!
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).
making programming simpler only means that simpler coders will be coding.
The reason girls and Windows users don't understand UNIX is because all the documentation is in Man files.
I don't think that it has much at all on automating the workflow, which makes sense to me. Tools and fuzzers are changing so fast that they aren't well served by books. I already have a few books on those topics, and they've all grown stale within a year or two.
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.
The fact that it's a bug and needs to be fixed hasn't changed. Its priority come debugging time just jumped up quite a bit because it went from a stability issue to a security issue.
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.
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.
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?
The tyrant will always find a pretext for his tyranny - Aesop