Slashdot Mirror


Defeating XP SP2 Heap Protection

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. Re:i know the drill by freeJustin · · Score: 4, Informative

    mayve you didnt read correctly this is a core issue, so to rephrase "I know the drill, *nix"

  2. Re:In hardware? by Anonymous Coward · · Score: 5, Informative
    How many of these rely on the hardware to protect them?

    Ummm... all of them?

    Memory protection requires hardware support to work, and every version of UNIX, Linux, NT (right from the beginning) and Win9x all use hardware support to implement memory protection.

    It seems that you have hardware memory protection mixed up with the NX (no execute) bit. All that the NX bit does is nothing more than mark memory allocated on the heap as non executable. The application is completely free to allocate executable memory, just that a normal malloc() does not cut it for this purpose.

    This is a very good feature. The reason is that 99.99% of apps never need to execute code created on the heap. The only exceptions are things that JIT code like the Java VM.

    Many buffer overruns that result in exploits rely on heap memory being executable. By requiring a very small set of programs to be fixed, you can eliminate a whole type of security flaw. Is it the be all and end all? No its not. But it sure helps.

  3. Re:In hardware? by Anonymous Coward · · Score: 2, Informative

    Most modern RISC processors have NX. I'm not sure if Alphas do, but most likely. Sparcs do.

  4. Re:NX bit? by YU+Nicks+NE+Way · · Score: 4, Informative

    The article description is a bit deceptive. NX is independent of DEP here. The alleged exploit only works for the small heap on machines without NX, not for machines with NX. NX stops this exploit cold.

  5. Re:And this by louarnkoz · · Score: 3, Informative
    Code execution protection is one of the security features of XP/SP2. The design concept in XP/SP2 is to have a succession of protection layers, e.g. running the firewall to block ports, requiring authentications on RPC ports that are open, blocking some form of communications, etc. None of these protections is entirely foolproof: some ports will remain open, some passwords will be guessed, etc. But it is much harder for an attacker to breach several protections than just one.

    The code execution protection is one of these protection layers, pretty much the last one when everything else has been breached and a buffer has overflown. It prevents the class of exploits that load code in a data buffer and somehow jump into it. But there is still a way through, using a stack overflow to rewrite a return pointer or a function pointer and direct it to an existing procedure, e.g. one in libc.

    Protecting against such exploits is very hard, and the problem is by no means specific to Windows. Don't expect a quick fix.

  6. Re:It shouldn't be a suprise. by ZorbaTHut · · Score: 3, Informative

    I disagree. Refactoring sounds like a much better solution. And I highly doubt this is a serious bug that affects the whole design - why would the introduction of a new CPU flag require the complete reconstruction of an entire OS kernel? Or more?

    I don't see how you could possibly suggest a full redesign and rewrite and then, in the same post, complain that fast fixes are rarely 100% correct. As if the rewrite won't be a thousand times worse!

    --
    Breaking Into the Industry - A development log about starting a game studio.
  7. Re:How does linux fix this? by Anonymous Coward · · Score: 1, Informative

    1. The 2.6 kernels have exec-shield support, which is a kind of emulation of the NX bit for processors that don't support it in hardware.
    2. Modern distros do address-space randomization which stops ret2libc type attacks.
    3. Linux doesn't have exception handlers so these don't need protecting.

  8. Re:An agrarian view on alternatives for XP SP2 by bluefoxlucid · · Score: 4, Informative

    BSD is under the BSD license. You may rewrite it, steal their code, and not give it out.

    You can build things with GCC and not GPL them.

    You can build things and link to libraries that are GPL and not GPL them.

    So, you can develope apps for linux, using only your own code and any code that BSD people threw under the BSD license, and build them against open source libraries to use those, and have an MS style EULA and closed source.

  9. Incorrect by Mark_MF-WN · · Score: 3, Informative

    He compared it to the morning after pill. The morning after pill doesn't "abort" anything -- it simply causes the egg to fail to implant itself in the uterus. This is EXACTLY what IUDs and "The Pill" do, and what happens in 90% of all fertilizations anyway. The morning after pill is just interventive birth-control. It has absolutely nothing to do with abortions.

  10. Re:NX bit? by hobo2k · · Score: 2, Informative

    I don't have the hardware to actually test it, but I believe the 2nd code sample is supposed to deal with NX. The stack/heap never get executed. Instead it modifies the stack such that when the function returns the C library function 'system' is called with an arbitrary command line to execute.

  11. Re:Question about the stack by pe1chl · · Score: 2, Informative

    This decision was made long ago, when there was only a single address space and it was convenient to have the program at a fixed address at the beginning of memory, and the stack fixed at the end.

    The "stack grows down" has been embedded in the hardware design and now it cannot be changed easily.

  12. Whooops, was that a typo? by cronius · · Score: 1, Informative

    You can build things and link to libraries that are GPL and not GPL them.

    Whoopsie daysie, that's not true. From gnu.org:
    If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?

    Yes, because the program as it is actually run includes the library.


    You can link non-GPL programs only with LGPL libraries.

    --
    Life is Reality