Slashdot Mirror

← Back to Stories (view on slashdot.org)

Defeating XP SP2 Heap Protection

Posted by michael on from the secure-by-design dept.

hobo2k writes "XP SP2 included canary values and hardware-implemented execution protection in order to avoid exploitable buffer overruns. Now Positive Technologies has released an article describing one way that protection could be bypassed. To solve the problem, they provide a program which disables the small allocation heap as described here. CNET reports that SP2 has been foiled."

13 of 242 comments (clear)

  1. NX bit? by Anonymous Coward · · Score: 3, Interesting

    I read the .PDF pretty carefully, but I still don't understand how DEP (data execution protection via the NX bit in the page tables) fails to prevent this exploit. The 1016 bytes of memory is on the heap, isn't it? So how is any code you put there going to be executed?

  2. This is way wrong. by A+beautiful+mind · · Score: 4, Interesting

    "Published 28th January 2005."

    And

    "In October 2004 it was discovered by MaxPatrol team that it is possible to defeat Microsoft® Windows® XP SP2 Heap protection and Data Execution Prevention mechanism."

    This is too much time to fix something. I can agree with some delayed disclosure but not anything above a month.

    --
    It takes a man to suffer ignorance and smile
    Be yourself no matter what they say
  3. In hardware? by MrLint · · Score: 1, Interesting

    Is it just me or is relying on hardware to protect your application heaps seem to be a bad idea. Not just because its non-portable (not that this matters for windows) but it basically offloads the work on HW that may or may not be up to the task.

    We know that unix, its variants and progeny, have memory protection. How many of these rely on the hardware to protect them? Certainly 'legacy' *nixes didnt run on HW that had these features.

    I guess what im saying is i dont like it as a long term strategy.

    1. Re:In hardware? by Anonymous Coward · · Score: 1, Interesting
      YOu don't eliminate a whole class of attacks, you just make them harder.

      Fair enough. Allow me to clarify - you do eliminate a whole class of exploitable attacks. This class of attacks are "Buffer overruns that inject code onto the heap and execute said code". NX changes that class of attacks to merely "Buffer overruns that cause the process to panic and quit".

      Remember, not all buffer overruns are created equal. Not all are exploitable. While all they are all clearly bad, NX turns certain explotable buffer overruns to non exploitable buffer overruns.

      But if most people don't have NX enforcement, then those that do are effectively safe for the moment.

      I do not understand this statement; it seems to be assuming that the existence of exploits that attack non-NX systems will deter people from working on exploits against NX systems. I fail to grasp that logic.

  4. It shouldn't be a suprise. by TeeJS · · Score: 4, Interesting
    that it's easier to bypass a patch over a hole, than get through a barrier that was built solidly from the beginning. I have a mental image of a steel door with a big piece of cardboard taped to it....

    --
    T.J. Schmitz - the man, the myth, the legend - o
  5. Fixed Quickly? by EventHorizon · · Score: 3, Interesting

    The patch may be quick. It will still take a long time to deploy.

    Anyway you have to wonder about this kind of technical oversight. If you are implementing an NX heap, you obviously need to NX the WHOLE heap for it to be useful.

    Basically it looks like Microsoft is incapable of secure development at the core OS layer. I find that absolutely mind boggling given their resources.

  6. plus, there's a chicken-and-egg impediment by js7a · · Score: 4, Interesting

    I don't think Windows users should lose too much sleep over this. How is an exploit supposed to unprotect the heap segment in order to execute the buffer overrun code -- before such code has been executed?

    1. Re:plus, there's a chicken-and-egg impediment by LO0G · · Score: 4, Interesting

      Exactly: In order to exploit this, you need to find a program with:

      1) An exploitable memory overwrite error in a system component.
      2) A heap allocation pattern that exactly matches the pattern demonstrated here.

      If you don't have BOTH of these criteria met, then it won't matter.

      Software DEP was never intended as anything more than a really big speedbump.

      As a PoC, it's interesting, but as "the end of XP SP2?" I don't think so....

  7. I blogged another way too by bluefoxlucid · · Score: 5, Interesting

    I did blog on another way using only a stack overflow on my blog. My way was more "all existing exploits work as-is after just a little extra step" than "exploits still exist that get around DEP" though.

    My way was to just slap DEP in the face by using a ret2libc with a constructed stack frame that gave the shellcode a nice, clean, executable area of memory to execute in, then copied the memory there, then returned to it. This is done by 1) Return to VirtualAlloc(), 2) Return to memcpy(), 3) return to shellcode.

    They noticed this in October; it took me until January and I'm not a security expert.

    --
    Support my political activism on Patreon.
  8. For the geeks... by Jugalator · · Score: 3, Interesting

    ... the juicy bits are here. Scroll down to the bottom for the appendices where there are C code examples on how to bypass these measures.

    --
    Beware: In C++, your friends can see your privates!
  9. Re:And yet by SirTalon42 · · Score: 2, Interesting

    Linux has for a good while. It also has 'Execute-Shield' which also makes buffer overflows much harder (implemented in software, and I believe works on more than just x86/x86_64).

  10. What the shit? by Anonymous Coward · · Score: 2, Interesting

    Okay, so in order to disable the heap protection either the user has to execute arbitrary code while running under the context of a user with sufficient permissions, or be enticed to follow a fairly obscure set of instructions to edit the registry.

    How the shit is this a vulnerability exactly? The only way to exploit it is to have already 0wned the machine so there would be no need to disable memory protection at any scope.

    Also, as mentioned, this doesn't work correctly on hardware that supports NX. There is no pure software method to carry out NX and all existing measures, such as DEP, can be defeated through complex means. Microsoft makes no claims to the methodology being 100% secure, but it will help stop 60% of buffer overrun scenarios which account for the vast majority of said vulnerabilities. But that is the only way to carry it out in code without imposing huge amounts of overhead, which would still be defeatable without hardware support. Developers practically have to go out of their way in order to embed such vulnerabilities. These proofs of concept are irrelevant; they are not representative of the forms of vulnerabilities accidentally introduced into software.

    In other words, another non-story from the shit-eaters at Snatchrot.

  11. Question about the stack by wirelessbuzzers · · Score: 2, Interesting

    The method of attack for most stack buffer-overflows is to write enough data into a stack-allocated object to clobber the return pointer, which is allocated above it.

    So why not make the stack grow upwards instead of downwards?

    --
    I hereby place the above post in the public domain.