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

Comments

CSA already does this

[wschalle]

Cisco Systems CSA product does this and more.

Not a silver bullet

[TwistedSquare]

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.

Re:What is a Buffer Overflow?

[RupW]

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.

Re:What is a Buffer Overflow?

[alc6379]

This is the way I understand it, and I'm not really a programmer. So, I know someone's going to clarify or refute:

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.

...And again, this is from one layman to another-- that's how I understand it.

Re:great news

[mchawi]

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.

Re:What is a Buffer Overflow?

[goombah99]

The most common form is as follows. When a subroutine is called the return address is placed on the stack. Then all the local variables for the subroutine are placed on the stack. the subroutine runs and when it finishes it jumps to the return address on the stack. However if the subroutine were to write data into an array or string on the stack and tried to push more data into the string than space was allocated it would continue writing past the end of the array and eventually overwrite the return address. This allows a way to substitute a new return address for a virus maker. If this return address happened to jump right back onto the string itself then in principle the data string will now be exceuted as code.

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.

Re:great news

[TheRaven64]

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.

Re:Umm...

[ctr2sprt]

This may sound really dumb, but isn't it up to the guy who wrote the vulnerability in the first place to fix it?

There is a time gap between when a bug is first discovered and when it is fixed. There is an even bigger gap between when a bug is fixed and when users actually bother to install the patch. Helping to prevent buffer overflows and the like will limit the problems caused by those gaps.

how the hell do you detect an overflow?

Memory is allocated using a library call like malloc(). Debugging tools will trap malloc() and actually allocate slightly more memory than is asked for, then write a signature before and after the buffer. It will then periodically check those signatures to see if they are still there. If they aren't - like because a program overwrote them with its own data - it means there's a buffer overflow. You can also use the CPU's virtualization hardware to spot some kinds of buffer overflows or other errors (like trying to read from a page that was allocated but never written to). There are other methods, but that's the most common and probably the easiest to understand.

Re:What is a Buffer Overflow?

[nudicle]

Quite a good writeup of stack buffer overflows can be found here.

Re:What is a Buffer Overflow?

[Just Some Guy]

You got it write, except that overwriting other data can be just as bad as overwriting executable code:

char buffer[100];
int dataHasBeenVirusChecked = 0;
gets(buffer);
if (dataHasBeenVirusChecked) { sendAsEmailAttachment(buffer); }

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.

Re:great news

[x0n]

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

Re:What is it with the buffer overflows?`

[codegen]

Part of the problem is the reliance on langauges which are over permissive. There was a whole class of languages developed in the 80's and 90's such as Euclid, Turing (both from U of T), and Modula which were much more strongly checked. Indeed the semantics of the languages allowed for many of the runtime checks to be statically eliminated. See the papers "Proof Rules for the Programming Language Euclid", R.L. London et al., Acta Informatica, And "On Legality Assertions in Euclid", D.B. Wortman, IEEE Transactions on Software Engineering.

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.