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."
The program disables the small allocation heap (meaning that the 1016 bytes of exploit code would be loaded into some other heap), which leads me to believe that perhaps the NX bit was only set for the small allocation heap pages. This will probably get fixed pretty quickly.
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 wonder what Nick McGrath's opinion on this is, and who is HE holding accountable?
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.
This is too much time to fix something. I can agree with some delayed disclosure but not anything above a month.
The CNET article states that they didn't report it to Microsoft until Dec 22. Which is close enough to the holidays that a substantial part of many businesses staff are out until the 1st of Jan.
Anything that modifies core memory access/rights such as this needs extensive testing. It's most likely an easy fix, but you should be well aware of the outrage that would occur if they released a fix that ended up breaking things. Recall the rushed fix to OpenSSH that was distributed only to be replaced days later with a proper fix, leading to all manner of confusion as to which versions were vulnerable and not?
Given that this is a relatively minor problem - the attacker would have to have another sucessful attack vector to be able to use this, I'm glad Microsoft is [theoretically] taking the time to do this right. If you're really that worried about it, you can run the software provided by a mostly unknown Russian company that they freely admit will affect the system negatively. And pray that there's no bugs in their code and that it's not malicious...
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
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.
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.
I agree. After reading the PDF, it seems that they were focusing on the software DEP system rather then the hardware (NX) DEP.
For those not in the know, XPSP2 has two forms of DEP. Hardware and Software. If your Processor supports it, WinXP uses Hardware DEP in the form of the NX bit to protect your PC. If the NX bit is not available on your CPU (Most CPU's fall under this category) then it defaultes to the Software DEP, or "sandboxing" as they put it.
If anyone wants to try and exploit this on an NX capable PC it would be interesting to see if it works. The Software DEP definetly is going to need some more work done to it though.
In Soviet Russia, Trojan exploits YOU!
Actually:
Don't make it sound like Linux is problem free either. Just this morning, *11* Linux kernel vulnerabilities were posted to security focus. Yes, the number of vulnerabilities in Linux have historically been fewer in number, but no operating system is perfect. Windows does what it does well: Providing a stable (yes, XP is stable,) operating environment for beginning to advanced users.
Mythos : Logos
"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.
And how long will it take to fix the Linux problems, compared to the Windows problem descibed in the article?
Linux way of fixing things:
1) Discover there is a problem
2) Send a patch to kernel maintainers
3) Kernel is patched
Windows way of fixing things:
1) Discover problem
2) Tell Microsoft
3) Two months later, when Microsoft has done nothing, tell the world
4) Get possibly sued by Microsoft (if MS can to a Russian company)
5) After several viruses have exploited the vulnerability, Microsoft makes a patch that won't install correctly.
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.
Well that's fine if people who really know what they are doing do the redesign and rewrite.
If it's the same people who didn't spot the serious bug that affects the _whole_ design, the odds are much worse that starting again would actually help much.
Ask a crappy team to redesign and rewrite and they'll just come up with more crap. Let's be nice and say the team is good only the politics/process is broken, whatever, you still end up with more crap.
So far the evidence is that more often than not the same people who wrote insecure software will still _rewrite_ insecure software even if they start anew. Go look at Bugtraq over the years.
It's hard for most programmers to write secure software in certain programming languages - C being the most infamous example. Trouble is most still keep doing so for various reasons.
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
The patch may be quick. It will still take a long time to deploy.
No, Windows has had automatic update for years now. Every machine I have is fully current with patches.
What would be the proportion of Linux systems running with heap protection?
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/