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.'"
Aha! (Score:5, Funny)
Yes, but if your pointer is NULL (Score:2, Funny)
If your pointer is NULL (Score:5, Funny)
Re: (Score:2)
The crux of the exploit: (Score:5, Informative)
To this address, controlled by attackers via wild offset, Flash writes a value that is also controlled by the attacker. This is the write32 pattern: a vulnerability that gives the attacker the means to set any one value in memory to a value of their choosing. Game over.
The exploit doesn't actually get to offset an arbitrary number of bytes from 0. A complicated set of conditions constrains the address it writes to and the value it gives it.
The the actual write occurs via a structure offset. Flash is hardcoded to translate your offset into another number. Working offsets, as it turns out, will be greater than 0x80000000, and will be evenly divisible by 12 after 4 is added to them. Note: I thought I was hardcore when I wrote shellcode with no lowercase letters for the IMAP vulnerability in the '90s.
That's not all. The value that Flash will write to the wild pointer isn't totally controlled by the attacker either. It's cast up from a 16 bit integer to a 32 bit integer, and has another variable subtracted to it. This is the point in the report that I started giggling uncontrollably, embarassing myself at the coffee shop...
To wit: his exploit must (because he's messing with us) corrupt the Flash runtime, rewrite it to execute his trojan, and leave it running steady as if nothing had happened. Meaning:
--His modification to the verifier can't break existing instructions. --His bytecode has to swap values into the stack instead of clobbering them directly. --Portions of his shellcode have to run as both Flash bytecode and an X86 first-stage shellcode boot.
Two fun details:
First, even though IE and Firefox use different Flash builds, the addressing inside them is compatible. The exploit works in both places.
Second, Flash isn't compiled with ASLR. So the attack works on Vista.
Mass casualty. Go Flash!"
Re:The crux of the exploit: (Score:5, Funny)
So... 0x8000000 is salt? (Score:2)
If so... why would they do that? Why not simply ensure that offsets can't go above, say, 0xffff, and then make sure program code/data is well above that?
Re: (Score:2)
Re:So... 0x8000000 is salt? (Score:4, Informative)
It's not a salt, it's just an artifact of how the Flash VM operates. There's a year-old post on Dowd's blog with a much simpler example of the same class of vulnerability: http://taossa.com/index.php/2007/04/15/bored-games/ [taossa.com]
Basically, the vulnerability occurs when you can write to an arbitrary offset from NULL. This is probably a common enough mistake that no one has been looking for because NULL derefs are usually just a crash bug. What Dowd has shown is that with a little application knowledge, and control of the deref value, you can make this type of bug into a perfectly reliable exploit that is unaffected by application hardening like stack canaries and heap checking.
Re: (Score:2)
A N
Re: (Score:3, Interesting)
Re:Big deal (Score:5, Informative)
Re: (Score:2)
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: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.
Non-issue (Score:2)
Re: (Score:2)
It can mess around with Flash and execute arbitrary code with either browser but not mess with the browser its self.
Re:Big deal (Score:5, Informative)
solves the problems on Ubuntu boxes as of this moment, so someone at Ubuntu is paying attention. Don't know about Debian, because I don't run Flash on any of my Debian machines.
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 bu
Re: (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)
Re: (Score:2, Informative)
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.
And just what do you think the JVM is written in?
Because underneath it all, the computer runs its native instructions. Period. The GP is a fucking moron if he thinks "throwing an exception" is a cure-all for insecure code. One guy develops a complicated NULL-pointer exploit that's valid in ONE virtual machine, and the GP reflexively supports banning C and C++.
Probably because he's too stupid to code properly without having some virtual machine interpreter holding his dick.
If you don't understand the con
Re: (Score:3, Insightful)
The GP is a fucking moron if he thinks "throwing an exception" is a cure-all for insecure code. One guy develops a complicated NULL-pointer exploit that's valid in ONE virtual machine, and the GP reflexively supports banning C and C++.
Crudely put, but correct. TFA outlines clearly the logic errors in the bytecode interpreter that make this possible. There's a period of time between input validation and usage that can be exploited and it is. Duh. There's an unwise distinct difference between how the input validator and the executor treat invalid input that can be exploited and it is. Duh.
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 kind
Re: (Score:3, Informative)
And, oh yes, WTF!!OMG!! - '...should be banned...'. Yeah, ban the filthy programming languages that don't babysit the programmer. While we are at it lets b
Re: (Score:2)
That is just silly, and demonstrates a lack of understanding of programming. High level langauges with built in checks and safties are very useful in a lot of situations, but they do not meet the needs when precision and control of the underlaying hardware is required. Whether flash needs this level of control I do not know, but plenty of applications do.
Furthermore, if you ban the low level languages, what are you going to write the high level language's byte-code interpreters in? You generally need a bit of low level stuff to bootstrap your virtual machine.
Re: (Score:3, Funny)
Re: (Score:3, Informative)
The first C compilers were written in assembly. What's GCC written in? C. More interestingly, what's Gnat (GNU Ada) written in? That's right. Ada.
How's that you ask? It's the very bootstrapping process you refer to.
As long as you can compile to machine code, there's no reason you ever need to write it. If you have a new machine, just make a cross-compiler in a high level language. Sure you need to have a native code generator at some level to createe the lowest level code that runs on the new mach
Re: (Score:2, Informative)
Re:The crux of the exploit: (Score:5, Informative)
Hold on a minute there, Captain Ivory Tower. Perhaps *your* C++ compiler does that. Mine (VC++, probably the most used compiler on the planet) does not.
With VC++6 it returns NULL. With newer versions it *sometimes* will throw an exception, but it depends on which libraries the linker happened to pull in first. See this link [microsoft.com] for more information.
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: (Score:2)
Don't blame the pipe-wrench for making a poor hammer. Blame the craftsman too lazy to find a hammer.
A more accurate analogy would be "don't blame the hammer because your shelf is uneven since you didn't bother to use a level.
Splint [splint.org]and friends will show up NULL pointer bugs very quickly even when using it's most liberal setting.
Of course the average C programmer hasn't progressed beyond not fixing compile warnings so they haven't gotten to the splint part yet. Sometimes I wish "-WERROR" was GCC's de
Re: (Score:3, Informative)
These get MUCH less rare when you crank up the warning and optimization levels. For example, the following idiom generates a warning in recent GCC versions if you turn -Wstrict-overflow on:
This tends to generate the following warning:
warning: assuming signed overflow does not occu
Re: (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: (Score:3, Funny)
If you are coding in C, you won't be in control of the machine for long.
Re: (Score:3, Insightful)
making programming simpler only means that simpler coders will be coding.
Re: (Score:3)
Besides, didn't people say the exact same thing to defend the use of hand-optimized assemblers against such inefficient bloated crap like C, and C against C++ ?
well, now that you mention it, let's see.. a stripped binary of cat (written in C) on my current system weighs in at 18,148 bytes.
My version of cat (written in asm) weighs in at 596 bytes.
Even if it was true, it didn't really matter, because computers keep on getting faster while humans don't, so moving more and more of the work from the programmer to the programmed is inevitable;
ah yes, the old, computers-have-so-much-power-we-don't-need-to-care line. in general, this may not be an issue, but there are some people who take this to the extreme, and some programmers who are either so bullheaded, or so retarded, that if they see any loss of performance, the fault is always that of the hardware. Bec
Binary blobs (Score:5, Insightful)
Comment removed (Score:5, Informative)
Re: (Score:2, Interesting)
Re: (Score:3, Interesting)
I do that on my Kubuntu desktop. I use Konqueror with gnash as my default browser, and when it can't handle something I right click and select "open this page in Firefox" (which has the adobe plugin installed.)
Re: (Score:2)
Re:Binary blobs (Score:4, Informative)
Actually, its just a major PITA, period.
Flash isn't any more secure on windows.
And there's no 64-bit version for windows either.
Windows x64 even ships with a proper 64-bit Internet Explorer 7, but it doesn't support flash. So to view flash in Windows x64, just like on Linux x64 you need to use a 32-bit web browser. Pretty sad.
And it goes without saying the a 64-bit build of Firefox (Minefield) doesn't work with flash on Windows x64 either.
Oblig (Score:5, Funny)
The Art of Software Security Assessment (Score:5, Interesting)
Re: (Score:2)
Re: (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
Cross platform? I don't think so. (Score:2)
Err , I'm sorry but how exactly do they expect x86 code to run on Sparc, or PA-RISC or PPC? etc etc. Even on the same architecture but a different OS all the interrupt vectors and API address calls will be different. Sounds like they're got a bit over excited to me. Or maybe I've missed some complex details of the exploit.
Comment removed (Score:4, Informative)
Re:Cross platform? I don't think so. (Score:4, Interesting)
The original article already has Russian trackbacks on it.
Re: (Score:2)
Re: (Score:3, Interesting)
The exploit already works on two (both Windows versions) out of those five. With some tweaking, it'll work on two more. With some additional work, it will also work on the last one.
The neat thing is that this single exploit can be used to break into any browser, on any operating system.
Anyone still believe that the secure browser from a
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Always check your return values! (Score:3, Informative)
The fact that Flash is doing all of these bytecode things also of course makes it more interesting. The first article linked seems to suggest that that makes the exploit really difficult (probably true), but it sounds like it also made it... well... possible.
Re: (Score:2)
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:Always check your return values! (Score:4, Insightful)
Re: (Score:2, Funny)
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.
You talk about "a modern OS", and then describe how WINDOWS uses its swap file.
"A modern OS" will most likely have fixed-size swap partitions.
hmm. (Score:2)
"does it run Linux?"
or in other words from TFA Win32 Firefox/IE prone to this technique, I'm assuming the code injection would only work on the target OS, no? I mean the CPU is specific, but also to work seamlessly you need to script it to to the target app. So it does not work on another processor (PPC etc) but also it would not work on any other application - so as the Linux binary is different then you are safe (until that one is attacked, but part of the secur
Re: (Score:2, Insightful)
does it run Linux?
Definitely. Just need to massage some asm code to make it fit.
part of the security of Linux relies on the smaller audience is not so attractive a target
Dude, if you feel safe just because you're running Linux, you could be surprised some day. Plus, the "smaller audience" is not so small anymore, thanks to Ubuntu and the like. On the other hand, projects like PaX and grsecurity, constant code reviews and bug monitoring do make Linux a pretty safe place.
Re: (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: (Score:3, Informative)
Re: (Score:2)
As others have pointed out in reply to similar questions, there probably isn't one single piece of injected exploit code that'll work on any operating system. However, Flash continues running after the injection, and can detect what platform it's running on, so an in-the-wild exploit could simply come with a selection of code to inject and choose what to do based on information Flash hands to it.
Re: (Score:2)
Yes if you install the Wine libraries.
Actually if the malicious code was written by someone with skill instead of the typical cracker wannabe and written in assembler it would run on ANY X86 platform regardless of the OS installed if it could use the same vector to get in. Granted it takes a bit more in the assembler program to then look and see, "Ok am I in a windows box? no, Linux? no, OSX? BINGO! Infection started....."
It really would not be that hard to do if you had the education
Why the java icon? (Score:5, Interesting)
When it comes a day after this flamebait article [slashdot.org] you have to start to wonder if the Slashdot editors are busy with some massive FUD campaign against Sun or if they are just really ignorant.
Re: (Score:3, Insightful)
Re:Why the java icon? (Score:5, Insightful)
Re: (Score:2)
Bah, I preferred my wild conspiracy theories. Anyway, if you needed another good reason to install NoScript [mozilla.org]...
Re: (Score:2)
Why Java? (Score:2, Informative)
Crap factor 11 Captain? (Score:3)
Wake me when something new happens.
Seriously, who in this day and age doesn't check the return codes of library routines when writing software that will be deployed on millions of computers?
Could someone please... (Score:2)
Obligatory Bad Pun (Score:2)
Dilbert became Flash-only today - coincidence? (Score:2)
Is it just a coincidence that the daily Dilbert cartoon has gone Flash-only today?
I have never liked Flash, mainly because it was used as a distracting and irritating advertisement medium, but also because of the arrogant assumption that the Flash page author should be in control of what my machine does. I don't want my browsing experience reduced to some funereal pace at the whim of a marketing drone who thinks his tedious animation should occupy my time.
I was reconsidering my decision to give up reading
Reason for the Excitement (Score:2)
Re:fubar (Score:5, Interesting)
Finally because it works on both IE and Firefox and Flash has such a huge installation base it should be able to target a very high percentage of current machines. Larry Osterman called it "The way the world (wide web]) ends [msdn.com]"
Mind you, if Address Space Layout Randomisation was turned on in the Flash executable on Vista, exploiting this hole would most likely (255 times out of 256) lead to a browser crash rather than arbitrary code execution, so it's not like the last few years work on security has been totally wasted. At the moment it's not and you will get owned reliably. Adobe have published an update, so it's a good idea to download it.
http://www.adobe.com/support/security/bulletins/apsb08-11.html [adobe.com]
Back when I was reading about security someone said that buffer overflows that execute code on the stack were first generation exploits. Second generation would be more subtle stuff like this.
Re: (Score:3, Insightful)
Re: (Score:2, Insightful)
This assumes, of course, that you know the entry point of libc's system(). Since glibc is typically a dynamically-linked ELF .so these days on Linux, this means th
Re:fubar (Score:4, Funny)
What's ironic.. (Score:5, Funny)
A browser crash is what's SUPPOSED to happen here to prevent the exploit from deploying its payload. I mean, in this case, a crash is the DESIRED behavior. An uncaught exception should be thrown.
So... just walk with me here... maybe Windows isn't just unreliable and unstable. MAYBE it's the most secure application stack ever devised.
Re: (Score:3, Funny)
Comment removed (Score:5, Informative)
Re:fubar (Score:5, Informative)
If you want to know something about the config, you type about:config and get to the super duper advanced settings page.
Re: (Score:3, Informative)
On mine, I see this:
Shockwave Flash
File name: NPSWF32.dll
Shockwave Flash 9.0 r47
Re: (Score:3, Insightful)
Re: (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
Re: (Score:2)
Re:boring? (Score:5, Informative)
Re:boring? (Score:5, Funny)
Re: (Score:2)
Layne
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:Is this new? (Score:4, Funny)
Re: (Score:2)
null pointers exploiting excited researchers?
What else can you expect from people whose job is to find security holes, study them and, dare I say, "fill" them.
Re:flashblock ftw! (Score:5, Informative)
Flashblock does not prevent flash running.
It removes existing flash from the DOM AFTER it has already been inserted and sometimes the initialization of the flash starts before it is replaced by the clicker.
Granted, most of the time it is removed before the ping time of the destination server with the SWF, but not always.
(Notice on a very slow page with lots of html you may see flash for a couple of seconds).
The only way to allow flashblock to block in a sane manner would be to replace the actual Flash binary with our own binary clicker that only calls the original adobe flash binary after clicking to view.
Everything else is a hack.
Re:flashblock ftw! (Score:4, Interesting)
Re: (Score:3, Interesting)
It may be interesting to see if noscript suffers similar issues.
Maybe some enterprising young security guy could investigate (send reports to flashblock so they an make improvements if required).
Re:flashblock ftw! (Score:4, Informative)
You are right, and I pointed that out at first, it doesnt happen most of the time, but it can occur.
go read the source.
http://www.mozdev.org/source/browse/flashblock/source/content/flashblock/flashblock.xml?rev=1.34;content-type=text%2Fplain;sortby=date [mozdev.org]
Look for the settimeout values which indicate you want a callback event raising after a specified period.
The period is set to 0, but as with all callbacks, I believe it does not run instantly.
(This code used to fail if you just call the flashblockShowPlaceholder() function directly because the actual DOM is not completely initialized)
Most of the time the flash will be blocked instantly, but if other threaded operations are ongoing and the page load is not simple then the flash actually gets time to run.
(If its totally changed and is really secure I will be very pleasantly surprised, but from the looks of things it hasn't yet).
Re: (Score:3, Interesting)
Try it on an old PC (450mhz in my case) with many applications running. I can often hear the sound from the Flash player advert or video before it is 'blocked'.
Re: (Score:3, Interesting)