Forgot your password?
typodupeerror
Java Programming Security

NULL Pointer Exploit Excites Researchers 327

Posted by Soulskill
from the ruh-roh-shaggy dept.
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.'"
This discussion has been archived. No new comments can be posted.

NULL Pointer Exploit Excites Researchers

Comments Filter:
  • Aha! (Score:5, Funny)

    by Rik Sweeney (471717) on Friday April 18, 2008 @05:29AM (#23115206) Homepage
    So you CAN get something from nothing!
  • by Ethanol-fueled (1125189) * on Friday April 18, 2008 @05:33AM (#23115222) Homepage Journal
    "...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!"
    • by slapys (993739) on Friday April 18, 2008 @05:43AM (#23115248)
      Dude. You are wise beyond your years. I hereby dub thee: the sensei of security.
    • You might need to dumb this down a shade for me, but from what I (think I) understand of it, it sounds like 0x8000000 is used as a kind of internal salt during bytecode compilation/execution for structure offsets so that the unchecked user code can't arbitrarily access structures?

      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?
      • by siride (974284)
        0x80000000 makes it negative in this case...I believe.
      • by n0-0p (325773) on Friday April 18, 2008 @09:06AM (#23116134)

        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.

    • by Stellian (673475)
      Except this is not a NULL pointer exploit. It's rather irrelevant how exactly you obtain the address needed to overwrite your target: in this case, you add up your controlled offset to a NULL base obtained after a failed malloc(), but it's just a rare circumstance. I ask you this: if the malloc call did not fail, wouldn't he still had control over the offset ? That's the major vulnerability right there, and he added the integer overflow to get a NULL pointer from malloc in order to stabilize the exploit.
      A N
    • Re: (Score:3, Interesting)

      by 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...
  • Binary blobs (Score:5, Insightful)

    by should_be_linear (779431) on Friday April 18, 2008 @05:37AM (#23115228)
    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 (Score:5, Informative)

      by CRCulver (715279) <crculver@christopherculver.com> on Friday April 18, 2008 @05:49AM (#23115268) Homepage
      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: (Score:2, Interesting)

        What I'd really want was some way to have both the proprietary flash player and gnash installed side by side and an easy way to switch between them. That way, you could just use gnash until you hit some file that it has trouble with and then just switch over.
        • Re: (Score:3, Interesting)

          by Peter La Casse (3992)

          What I'd really want was some way to have both the proprietary flash player and gnash installed side by side and an easy way to switch between them. That way, you could just use gnash until you hit some file that it has trouble with and then just switch over.

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

    • by ardor (673957)
      I recommend to watch this one: http://en.wikipedia.org/wiki/Gnash [wikipedia.org]
    • Re:Binary blobs (Score:4, Informative)

      by vux984 (928602) on Friday April 18, 2008 @07:26AM (#23115600)
      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 (Score:5, Funny)

    by Anonymous Coward on Friday April 18, 2008 @05:39AM (#23115232)
    NULL to see here, move along to 0x80000001 please...
  • by MadMidnightBomber (894759) on Friday April 18, 2008 @05:39AM (#23115234)
    (book by Dowd, McDonald, Schuh) is well worth a look: http://taossa.com/index.php/author/mark/ [taossa.com]
    • by n0-0p (325773)
      Yeah, that book has become bible on vulnerability research. There's really nothing else comparable if you want to understand how vulnerabilities work, and how to find them. The odd thing is that it's style is more directed at programmers than security people.
  • FTA: "is not far off being cross platform "

    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.
    • by lisaparratt (752068) on Friday April 18, 2008 @06:13AM (#23115332)
      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.
    • by Alioth (221270) <no@spam> on Friday April 18, 2008 @06:15AM (#23115338) Journal
      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.
    • by bcmm (768152)
      I think they mean that the flaw they exploit exist on multiple platforms. The actual payload to be executed would of course have to be re-written.
    • Re: (Score:3, Interesting)

      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
  • by Anonymous Coward on Friday April 18, 2008 @05:58AM (#23115288)
    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.
    • Thanks for the tip :p I don't think I've used malloc for a few years personally, but this is a useful thing to keep in mind for future applications. I wonder how many /.ers know that it can even be exploited in this way - I certainly don't know much about security exploits.. I'd have no idea how I'd go about exploiting buffer overflows and null pointer exploits like this, though I can imagine it would be a fun exercise :P
    • by Tony Hoyle (11698) <tmh@nodomain.org> on Friday April 18, 2008 @07:24AM (#23115592) Homepage
      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.
      • by siride (974284) on Friday April 18, 2008 @08:43AM (#23115988)
        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.
      • Re: (Score:2, Funny)

        by Anonymous Coward

        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.

  • finally a decent opportunity to ask...

    "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)

        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: (Score:3, Informative)

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

    • by Lumpy (12016)
      "does it run Linux?"

      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)

    by LarsWestergren (9033) on Friday April 18, 2008 @06:46AM (#23115448) Homepage Journal
    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: (Score:3, Insightful)

      by Roofus (15591)
      I was wondering the same thing with the Java tag. My thought is the editors are actually ignorant and biased.
    • by baadger (764884)
      Java is JIT'd in a VM, this Flash exploit is essentially about busting through VM's. There is vague linkage here.
  • Why Java? (Score:2, Informative)

    by vvsiz (612267)
    How on Earth this is Java related and tagged with 'java' keyword?
  • by Nomen Publicus (1150725) on Friday April 18, 2008 @07:06AM (#23115536)
    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?

  • explain this event in terms that a person with a sex life not involving the Internet could understand?
  • Null is a four letter void.
  • 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

  • Anything involving misbehaving NULLs excites old LISP programmers.

Truly simple systems... require infinite testing. -- Norman Augustine

Working...