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.'"
"...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.
...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 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!"
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.
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.
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.
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.
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.
Comment removed based on user account deletion
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.
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.
liqbase
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.
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.
I'm old enough to remember when discussions on Slashdot were well informed.
about:plugins 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
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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/
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.
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
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).
liqbase