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

The crux of the exploit:

[Ethanol-fueled]

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

Always check your return values!

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Big deal

[Trouvist]

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.

not boring

[Anonymous Coward]

null pointer's are very common errors in software, but are extremely hard to exploit. It almost never happens. This is why it's interesting.

Re:boring?

[starling]

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.

Why Java?

[vvsiz]

How on Earth this is Java related and tagged with 'java' keyword?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Binary blobs

[vux984]

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.

Re:The crux of the exploit:

[martinmcc]

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 ban corners, very dangerous.

Re:flashblock ftw!

[LiquidCoooled]

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:The crux of the exploit:

[Rogerborg]

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.

Re:The crux of the exploit:

[Anonymous Coward]

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 consequences of the code you write, you're incompetent and in over your head. Banning specific languages won't improve your comprehension.

Re:fubar

[orasio]

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

[Simon Brooke]

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

[X0563511]

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

[n0-0p]

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

[dysfunct]

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.

Re:flashblock ftw!

[LiquidCoooled]

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:Binary blobs

[martinw89]

Just wanted to mention that Swfdec [freedesktop.org] is coming along quite nicely also. It already plays all the popular FLV video players. Plus it has some cool features, like a universal "play" button on all the media it handles so you don't get assaulted by flash.

Re:The crux of the exploit:

[T.E.D.]

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:flashblock ftw!

[Anonymous Coward]

NoScript [nosccript.net] does prevent Flash from running.

Re:The crux of the exploit:

[Anonymous Coward]

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 statement is simply false. Java is written in C/C++ and has had a number of memory corruption vulnerabilities identified in it. Further, all those Java objects are passed around as references, so I certainly wouldn't discount someone finding an exploitable NULL pointer dereference.

I do agree that Java makes such bugs a lot less likely, because they can occur in only the platform and JNI modules. However, it does not make you immune.

Re:fubar

[RKThoadan]

Well, until now it was generally consdiered an un-exploitable error. Now it's not. That changes things.

Re:The crux of the exploit:

[leuk_he]

If you read teh article you read that flash uses bytecode, just like jave, and that a part of the exploit was exploiting one byte of cehcks on the bytecode.

If you know java/JVM like he exploited flash bytecode, you can exploint null derefeneces just like he did with flash in java.

JIT, with all kind of crazy optimizations will make it only worse.

The problem is that you can break out the virtual machine(/application) if you knwo it well enough.

Even virtualisation will not fix this. Look at the vmware 1.05 release notes and you see that there was a exploit where the client could write in the ENTIRE host file system.

Re:The crux of the exploit:

[Mr Z]

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 machine, but that native code can be generated from as high a level language as you like once you have a sufficient software stack.

Of course, such bootstrapping has its own problems. [bell-labs.com]

Re:The crux of the exploit:

[Mr Z]

Unfortunately, there are [rare] times when it is necessary to write code which generates compiler warnings.

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:

for (i = 0; i < len; i++)
. . if (foo[i] == blah)
. . . . break;
if (i == len)
. . return -1; /* not found */

This tends to generate the following warning:

warning: assuming signed overflow does not occur when simplifying conditional to constant

*sigh*