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."
firefox
Now Positive Technologies has released an article describing one way that protection could be bypassed.
A security problem in Windows? no way...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Protection? What protection?
C'mon, this has been known for a while ;)
Error 407 - No creative sig found
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?
> Microsoft and security?
;-)
> Chalk and cheese?
Don't you mean simply "swiss cheese"?
"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
T.J. Schmitz - the man, the myth, the legend - o
I'm surprised about the reporting that SP2 has been "foiled". SP2 is supposed to be a step to make xp more secure, not invincible. There's a lot more to SP2 than the heap protection.
I'm shocked! I have been reading all these independent studies, and according to Forrester, Windows users have fewer vulnerabilities. Check it out yourself, if you don't believe!y stem/facts /analyses/default.mspx#EHAA
http://www.microsoft.com/windowsservers
It's a fact. So this vulnerability, and the dozen others I've been patching at the work, are just some kind of imagination. Or maybe Linux / BSD / OS X users have just amazing amounts of vulnerabilities (counted together, OS & apps).
I'm drunk. And it's not a surprise. Every hardcore Linux geek (like myself), who has to maintain Windows networks for living, have more drinking problems than those who are using solely operating systems and software which are free as speech (as opposed to beer).
Responsible for security of Windows network? Next recommendation for security enhancements: different operating systems, no more IE. If there are costs, then they're definitely worth it. Microsoft has proved that they don't care. All they care is money, monopoly and marketing (FUD / brainwashing / propaganda).
I wonder what Nick McGrath's opinion on this is, and who is HE holding accountable?
You expect the links and the article to be related?
You expect too much from the editors.
DarkMantle I been bored, so I started a blog.
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.
Last I checked it already was.
f ee677def32a8cc4d1b858f99/ n alContent/0,289142,sid39_gci969248,00.html/
http://news.zdnet.com/2100-3513_22-5227102.html/
http://linuxgazette.net/107/pramode.html/
http://kerneltrap.org/node/3240?PHPSESSID=262a094
http://searchenterpriselinux.techtarget.com/origi
Just to name a few
Help Brendan pay off his student loans
When asked about the problem Steve Ballmer said that Linux sucks.
CNET reports that SP2 has been foiled.
Shouldn't that read tin-foiled? C'mon, slashdot, standards?
Most modern RISC processors have NX. I'm not sure if Alphas do, but most likely. Sparcs do.
...probably Nick McGrath ;o)
...Rob
The American Dream isn't an SUV and a house in the suburbs; it's Don't Tread On Me.
Yeah. A bit sensationalist, I suppose. And SP2 did live up to the ideal of making Windows more secure, but the typical user mentality operates more in the realm of absolutes. "I want perfect security, and SP2 isn't perfect so therefore it's useless." Good security is a process, a continuing evolution, and that's true no matter what OS you use. Would I plug an XP SP2 box right into my cable modem? Not unless I was setting up a honeypot. But it is an improvement.
The higher the technology, the sharper that two-edged sword.
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.
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?
This is probably a good thing, because it proves that even with stackguarding, etc.. Treating your system as if they dont exist is the best thing you can do. Microsoft unfortunately chooses to use stackguarding as a first line of defence to allow them to take their time patching software, which is a terrible idea.
So basically, nothing has changed in the security world in the past year. The only thing is that the attitude of programmers have in some cases, become slacker because of technologies like this, believing they can get away with it now.
If you ask me though personally, I'm betting Microsoft didn't run major tests on the security of DEP anyway, only simpler ones
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.
... 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!
Since MS claims Linux companies can't be held responsible for Linux security, will MS claim responsibility for this?
I'd rather have someone respond than be modded up.
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.
If you really read comments at +3, you're reading the same stupid-ass crap that gets posted in every fucking story.
What's the mother fucking point of reading the comments if you're going to let other people decide for you which ones are good enough to read?
Naturally, the only real solution is to avoid the overruns by sensible code. But, if one would be ready to believe that this level of checking would be enough to put native compiled code written by idiots on par with Java or .NET code written by idiots in the area of buffer overrun, it would be a cheap choice, performance-wise.
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.
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.
Support my political activism on Patreon.
"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."
/bin/sh /bin/sh /bin/sh /bin/sh "
Exec Shield protects the stack, unless something's mapped above it, or unless it thinks you need an executable stack. It protects other things, randomly; the protections randomly fail. Spender also has a working exploit that takes out ES, but he can't distribute it or disclose the method because (as he needs food) he sold it for $1000 to a security firm.
The stack can be used for code or for some data. The stack can be stuffed with 0x02020202 (NOPNOPNOPNOP) so that the shellcode can be shifted off and you either A) jump to the shellcode, or B) jump to NOPs and run to the shellcode. For things using the stack for data (like shell returns to preexisting code that's not randomly placed under most systems), you can rely on the stack being aligned to 16 bytes. "/bin/sh
PaX has proper NX protections.
"2. Modern distros do address-space randomization which stops ret2libc type attacks."
You need to use GrSecurity's brute force deterrance to do this on fork()ing daemons like apache, else the randomization is breakable. PaX' can be broken in 216 seconds; the one from ES normally can be broken in one step by stack stuffing (64k or 2M rand, one of those two).
Brute force deterrance is useless for small randomization, because you can use a certain trick to evade them involving holding off the attack until you set up for doing it several times in parallel.
PaX has better ASLR.
"3. Linux doesn't have exception handlers so these don't need protecting."
Your right, the OS doesn't. The programmer has to code for exceptions and signals. The OS can't protect them, but you can create a compiler modification that does so. It's pointless though, really. The same things in PaX that kill your normal exploit kill your mucking with signal handlers.
Support my political activism on Patreon.
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.
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.
You didn't hear anything about buffer overflow in DOS simply because there are much simpler way to run arbitrary code, whenever you want.
you can simply register an interrupt handler, for the clock, if you need to do something every clock tick, or to int21 (dos function calls) if you want to do something when a program calls dos functions.
Omry.
If you browse at +3, you will miss a lot of funny as well as lot of rather intelligent posts you wouldn't get to see at +3.
Also, reading at -1 raw and uncut shows in rather stark clarity that the moderating system at slashdot is broken
Dawn of the Dead