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

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

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

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