Slashdot Mirror
Data Execution Protection
esarjeant writes "In addition to a number of other security features, anti-virus vendors are starting to push buffer overflow detection. This will be part of Microsoft's future direction with Data Execution Prevention (DEP) and is already integrated with McAfee 8.0i. So it looks like everyone is going to upgrade all of their software again, will software vendors be able to keep up with the support calls?"
Wikipedia to the rescue
Cisco Systems CSA product does this and more.
DEP will not prevent all buffer overflow attacks. It is intended to protect from the attack where the return address of the stack is overwritten to make the program jump into the stack. However, the program could still jump into a useful portion of existing code, or simply crash, or keep running but overflow a flag variable on the stack that will cause odd behaviour. It can also prevent things like JIT/HotSpot compilation. I'm not saying it's not useful at all, but it is one of many measures that all help a little.
It's usually where you've assume that user input or decoded data won't exceed a certain length, and if the user deliberately enters too much data then they can scribble over the call stack and e.g. change the function return pointer and take control of the program. See Wikipedia.
You have some memory allocated for some type of variable, or something. That's called a buffer, and it's usually a certain number of bytes "big". There's a function in your program that puts a value into that variable. If you can feed more data into the buffer than it can handle, you can have a buffer overflow.
The reason why this is dangerous is because that data "spills" into another portion of the memory, which could already be occupied by anything from more data, to executable code. In the latter case, if you've overwritten executable code, you can replace that code with your own executable code, and do all kinds of nasty things that the original program wasn't intended to do.
I don't moderate anymore. Karma penalty for 90% fair mods? Can I mod that unfair?
Well, the 386 series processors already have to capability. Code and data segments are separate things - it's just never actually been set up in the operating system. Check out the type flag in the segment descriptor.
This sig made only from recycled ASCII
Great explanation of buffer overflows here
____
~ |rip/\/\aster /\/\onkey
It was included with Windows XP SP2. It's also in the soon-to-be-released SP1 for Windows Server 2003.
It appears that if the hardware doesn't support DEP, it will enable some sort of software DEP, instead.
W2K3 SP! also includes a new, XPSP2-like firewall interface with some nice logging and an easy-to-use rules interface. There's also the new Security Configuration Wizard, which seems to do a pretty damned good job of really locking down 2003 for those that need it.
Check Google with a string like Linux NX AMD. There have also been several slashdot stories about it. The short answer is yes it is available, but I don't know how widely used it is.
partial remedial solutions include commands that prevent decleared data from being executed, having the return address stored on a different stack from the data stack, explicitly testing the stack integrity before executing a return from a subroutine, and putting up "electric fences" --basically buffer regions around every memory allocation that are not owned by the application requesting space.
Some drink at the fountain of knowledge. Others just gargle.
Not sure about Linux, but OpenBSD has a number of features which protect from this kind of vulnerability. This is why a lot of arbitrary code execution vulnerabilities become DoS vulnerabilities on OpenBSD.
I am TheRaven on Soylent News
See, I appreciate this explanation, and the one below which reframes the explanation as occuring on the stack. These are the explanations I've always understood. And which, frankly, didn't fully cut it with me.
*Many* moons ago, I took an OS writing course from Intel, on the 80286. The way I was taught, a buffer overflow is something that would not have been possible in the processor architecture. There were code segments, and data segments. If ever the twain should overlap, processor exceptions occur, whether on the heap on in the stack. Just intercepting these faults took a major act of god on the part of the processor's primary process.
The, a few years later, I got a reeducation in the same coure, only on the 80386. Heck, there was even more protection for processes on that processor. A lot of stuff that had to be implemented in software before, like determining which process caused the fault above would be done in hardware.
OS2 2.2 was so bullet proof mainly because it took such good advantage of these hardware protective mechanisms. When I read Gates's screeds against OS2, I find myself either laughing hysterically or yelling "liar" (because he tells some pretty huge whoppers about the development).
Add to all this, most OSes dynamically allocate memory to processes, so even if you could overlay code with data and manage to get it executed, getting it to overlay in the right place and on the right byte boundardy without causing a fault would seem pretty unlikely.
I guess as one who doesn't try to write malware, just the very idea of these overflow explanations seems so unlikely that even if I were wanting to write such programs, I wouldn't consider buffer or stack overflow as an idea.
I suppose I'm saying, the explanations I've heard about buffer overflow make sense to a point. And then they seem to run up against facts as I know them. I'd like to see explanations of buffer overflow that make complete sense.
i386 architecture as I understand it allows the OS programmer to place the processor in a mode which basically defeats all the code vs data and process control mechanisms in the hardware. In my understanding, this is something done only at boot time, and only for the period of time necessary to set up the code which kicks the processor into a hardware mode which supports memory and process partitioning for multitasking. Please don't tell me, not even as some karma raising "funny" joke, that Microsoft doesn't even use the hardware modes which I would presume would prevent buffer overflow from ever occuring?
Quite a good writeup of stack buffer overflows can be found here.
It's built-in to OpenBSD and has been since V3.3 (currently shipping 3.6, 3.7 due in 2 months).
People should not be afraid of their governments - Governments should be afraid of their people.
In this case, if "buffer" gets overfilled just so, then the program may incorrectly believe that the data it contains is safe to operate on even though it might not be. Remember, folks, there are other ways to exploit an overflowable buffer then the standard "write executable code to stack and jump to it" method.
Dewey, what part of this looks like authorities should be involved?
I'm kind of a jr programmer and here's the idea I had. Could be done by the compiler and is probably already out there in some form.
;-)
Character arrays have an extra byte stuck on the end of them. When the compiler sees that it's being called by an unsafe method or some sort of strcpy it puts a random value into that byte, and rechecks it after the call. There is no way for the buffer overflow code to know what the value was and when it is changed the program is immediately killed. Then again your overflows still have a 1 in 256 chance of working.
So is this already being done somewhere or is there any reason why this just wouldn't work?
Seems to me OSS along with GCC has the potential to fix overflow problems a LOT easier than a commerical OS vender could.
-Don.
Cwm, fjord-bank glyphs vext quiz
Yes, but nothing stops user apps from ignoring segment descriptors -- and the operating system cannot easily check the type flag before executing the code. On the other hand, the NX (no execute) flag causes a _hardware_ interrupt which cannot be ignored by the user app if the O/S decides to act on it.
- Oisin
PGP KeyId: 0x08D63965
Yep, it does. With the grsecurity patchset, you can disable memory from being executed.
Also there are tons of open source tools
stack guard and libsafe and so forth all available for linux that check for buffer overflows in general.
can't the PC guys check their goddamn counters and pointers when using buffers?
We try our best, but we're humans. We make mistakes.
And why the hell do we still need to code buffers? Isn't there a library or a call to handle buffers in a safe way?
Yes. In fact, most modern languages like Java and C# handle memory for us; no more deletes necessary, and buffer overflows, while not impossible, more much less likely to happen with higher level languages.
Tech, life, family, faith: Give me a visit
I've had stack protection for quite some time with Solaris and OpenBSD. The Windows platform is a few years late to the party; doesn't Microsoft realize how much easier their life would be if they acted earlier?
Companies with Windows are like a person persisting to wear worn-out shoes. They're uncomfortable, they cause blisters, they don't keep water out, yet they keep them, because going barefoot is worse, I guess. The software industry still has a lot of growing-up to do.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
The problem you are describing is not with Windows or Linux. What you are describing is in fact exactly the lack of a "NX" bit. The Intel processors could not make memory readable and not be executable. Thus if you want to read the data on your stack then it was also possible to jump to it and execute it. The fact that Windows or Linux were unable to fix this problem is not their fault.
Possibly you are confused by 80286 segments, which could make memory readable without being executable (because you could only execute by loading the PC segment register, and the OS could apply totally different rules depending on which segment register was being loaded). However apparently the 80286 scheme has a lot of problems which is why neither Windows or Linux use it for virtual memory (I am not sure what the problems are but it is obvious nobody wanted to work with it).
C and C++ put the reliance on the programmer to check the rules under the assumption that compiler provided checks are too expensive. They are only too expensive if you assume the everthing-is-a-pointer model that underlies these languages. Java and C# gain some safety since they do not allow arbitrary pointers, but, in my opinion, have still inherited too much from the parent laguages.
Part of the problem is the everything looks like a nail approach. There are some wonderful languages out there that are much more appropriate for many of the tasks, and have syntax and semantics that make many of the security problems much easier to solve. However, they are not the "mainstream" langauges and as such do not get the developer attention.
Atlas stands on the earth and carries the celestial sphere on his shoulders.
Please, do not pirate closed source viruses. Instead, use open source viruses, which you can get for free.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Does Linux have something like this? Fedora has had Exec-Shield long before Windows had DEP.
This description of the problem is flat-out wrong.
Nobody uses segments any more. Win32 programming uses a flat 32-bit address space.
The problem stems from the fact that, under the Intel architecture, procedure local variables are allocated on the stack right next to the return address pointer. If a lazy programmer allocates a 256 byte buffer and does a strcpy() that doesn't have a null within the first 256 bytes, strcpy() will keep copying data until it hits a null character, clobbering the return address (and other context information for the previous stack frame) as it does so. When the current function hits a RET instruction, the processor will jump to the overwritten return address.
DEP does nothing more than expose existing bugs. If your code triggers DEP, you already had a bug in your code... be thankful that DEP points this out to you!