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.'"

Aha!

[Rik Sweeney (471717)]

So you CAN get something from nothing!

If your pointer is NULL

[superbrose (1030148)]

...you'll need a pointer first.

The crux of the exploit:

[Ethanol-fueled (1125189)]

"...Not this time. Flash forgets to check that allocation failed, a ludicrously common error. It then uses that pointer with an offset controlled by the attacker. NULL isn't valid. NULL plus 1024 isn't valud. But NULL + 0x8f71ba90 is, as is NULL + N for any N that addresses valid memory.

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...

...The net result of this silliness is that it's hard to do what attackers normally do with a write32 vulnerability, which is to clobber a function's address with a pointer back to their buffer, so that their shellcode is called when the clobbered function is called. So Dowd's exploit takes things in a different direction, and manipulates the ActionScript bytecode state.

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:

[slapys (993739)]

Dude. You are wise beyond your years. I hereby dub thee: the sensei of security.

Re:

[dargaud (518470)]

I don't know either flash or VMs in general, but in order for the attacker to return a fake value from a malloc call, shouldn't the attacker already have control to libc (in C) or to the internals of the VM in that case ? Meaning he already can do whatever he wants...

Re:Big deal

[Trouvist (958280)]

It can run anything. If you read the paper, it explains that once you desynchronize the interpreter from the validator, you are running x86 instructions. One might have to tailor the exploit to work differently on Linux/Unix than on Windows due to the different executable addressing schemes, but once that is determined you are in business.

Re:Big deal

[by Anonymous Coward]

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

[n0-0p (325773)]

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:Big deal

[Simon Brooke (45012)]

I don't think I'll be updating adobe on my linux box just yet.

sudo apt-get update; sudo apt-get upgrade

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:

[jo42 (227475)]

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.

Re:The crux of the exploit:

[hey! (33014)]

The kitchen? No. The Nursery? Might be a good idea.

Re:

[martinmcc (214402)]

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.

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:

[Waffle Iron (339739)]

Furthermore, if you ban the low level languages, what are you going to write the high level language's byte-code interpreters in?

Why, turtles of course. Turtles all the way down.

Re:The crux of the exploit:

[pla (258480)]

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.

Re:

[spir0 (319821)]

Assuming that Flash is made in C or C++, here is another very vivid example of why these languages should be banned.

look, there's really no nice way of saying this, but ... well, you're an idiot.

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:

[T.E.D. (34228)]

remember: you are in control of the machine, not the other way around.

If you are coding in C, you won't be in control of the machine for long. :-)

Re:The crux of the exploit:

[T.E.D. (34228)]

The default C++ new does throw an exception rather than returning NULL, but don't let your
ignorance of the language stop you from decrying it.

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:So... 0x8000000 is salt?

[n0-0p (325773)]

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.

Binary blobs

[should_be_linear (779431)]

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.

Re:Binary blobs

[CRCulver (715279)]

There's always Gnash. FWIW, the only Flash applications that I can't get to work with Gnash are YouTube-like video players, and I usually prefer to download those as .flv files straight to my computer with a Firefox extension.

Re:Binary blobs

[vux984 (928602)]

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.

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

[by Anonymous Coward]

NULL to see here, move along to 0x80000001 please...

The Art of Software Security Assessment

[MadMidnightBomber (894759)]

(book by Dowd, McDonald, Schuh) is well worth a look: http://taossa.com/index.php/author/mark/ [taossa.com]

Always check your return values!

[by Anonymous Coward]

The moral of the story is a point that many of us have already been making for years: check the return value of malloc. I've had lots of arguments over whether or not it's okay to omit that and let your program crash for the poor sap who hasn't got any heap left. Unfortuantely a common attitude is, "the program is screwed anyway at that point, so who cares?"

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:Always check your return values!

[Tony Hoyle (11698)]

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.

Re:Always check your return values!

[siride (974284)]

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.

Why the java icon?

[LarsWestergren (9033)]

The paper specifically talks about the ActionScript virtual machine, i.e. the Flash player VM. There is nothing in there about Java. Why the Java icon? Why the Java tag?

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:

[Roofus (15591)]

I was wondering the same thing with the Java tag. My thought is the editors are actually ignorant and biased.

Re:Why the java icon?

[ChunderDownunder (709234)]

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.

Crap factor 11 Captain?

[Nomen Publicus (1150725)]

Crappy programming allows successful hacking?

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?

Re:Cross platform? I don't think so.

[lisaparratt (752068)]

For x86: you use the Flash APIs to determine which actual platform you're on, load the code appropriate for the platform, and then use the exploit to execute it.

Re:Cross platform? I don't think so.

[Alioth (221270)]

The only cross platformness it needs is browser cross platformness. 95% of desktops run Windows on x86. Since I suspect Flash doesn't get updated as often as Windows or Firefox (and I suspect many users don't even update those) this is going to be quite an effective way of making a botnet.

The original article already has Russian trackbacks on it.

Re:

[by Anonymous Coward]

It relies on Flash. Flash is only available in five versions - Windows / x86 (as an ActiveX control, and a Netscape plugin), Linux / x86, Mac OS X / PPC, and Mac OS X / x86.

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:fubar

[Hal_Porter (817932)]

This interesting because he's exploiting a malloc fail. The gory details of exploiting ActionScript is also cool because it has a bytecode verifier and he manages to get around it. It really is a lot more high tech than a typical stack buffer smash against a badly written C application, and that is important because everyone should hopefully have updated that sort of code to be exploit free by now. And stack checked binaries and data execute prevention, AMD's "Not Execute" bit, make those more likely to end in process death than arbitrary code execution.

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:

[by Anonymous Coward]

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?

Re:fubar

[by Anonymous Coward]

You don't have to come across this exploit for your browser to crash in Vista, normal browsing does that just fine.

What's ironic..

[encoderer (1060616)]

What's ironic is that this exploit DOESN'T crash the browser! That's the whole ever-fuckin point.

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. ...oh, hell...nevermind

Re:fubar

[liquidpele (663430)]

Since I couldn't find where to look in the firefox menus, you can find out your current version by visiting this page: What is my version of flash? [adobe.com]

Re:fubar

[orasio (188021)]

FYI: you can type about:plugins in the address bar, when you need to know anything about plugins.
If you want to know something about the config, you type about:config and get to the super duper advanced settings page.

Re:

[X0563511 (793323)]

about:plugins [about] is what you want. Why this isn't linked or otherwise brought to light, I don't know. I discovered this by trial/error and/or boredom.

On mine, I see this:

Shockwave Flash
        File name: NPSWF32.dll
        Shockwave Flash 9.0 r47

Re:

[Hal_Porter (817932)]

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.

Re:boring?

[starling (26204)]

It's an impressive hack, or series of hacks rather, so I wouldn't say boring. The interest is not that the exploits are anything new (they aren't), but in the difficulty of pulling it off.

Re:boring?

[somersault (912633)]

This is more like a cat up a tree armed with a sniper rifle, picking off any emergency service personnel that get too close while his buddies rob a bank.

Re:boring?

[ubernostrum (219442)]

Wow, an error in a program. This seems akin to ground-breaking front-page news: a cat stuck in a tree rescued by firemen.

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?

[somersault (912633)]

That's what the aliens get for abducting Bill Gates and basing their Mothership's OS on values obtained while probing his anus..

Re:flashblock ftw!

[LiquidCoooled (634315)]

I am also a huge fan of flashblock (I helped code up some bugfixes for it in a prior version), but be aware of its limitations.

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!

[Hatta (162192)]

Or use NoScript. I don't know why anyone would use Flashblock when there's NoScript.

Re:flashblock ftw!

[LiquidCoooled (634315)]

Yes, I am sure.
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:

[JasterBobaMereel (1102861)]

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 ....

Re:

[dysfunct (940221)]

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 ....

What exactly do you mean? Any x86 code will either pretty much have to use syscalls to do anything useful and thereby run under normal user privileges or - as you said - will cause exceptions because it's not running in ring 0 and can't do anything privileged on the hardware side of things.