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

Comments

i know the drill

[numike]

firefox

Re:SP2 what?

[A beautiful mind]

it's like putting on a second condom AFTER sex when the first one proved to be leaking.

Re:Is that link to MS correct

[DarkMantle]

You expect the links and the article to be related?

You expect too much from the editors.

Re:In hardware?

[Anonymous Coward]

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.

Re:Linux/NX/AMD64

[DaHat]

Last I checked it already was.

http://news.zdnet.com/2100-3513_22-5227102.html/
http://linuxgazette.net/107/pramode.html/
http://kerneltrap.org/node/3240?PHPSESSID=262a094f ee677def32a8cc4d1b858f99/
http://searchenterpriselinux.techtarget.com/origin alContent/0,289142,sid39_gci969248,00.html/

Just to name a few

I blogged another way too

[bluefoxlucid]

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.