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

Virus vendors?

[King Of Chat]

Who buys viruses?

support calls

[millahtime]

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?

Yes, with more automation, more people on the other end (most likely in India) and more cost passed onto the customer. When I used to work we used to have a saying. "If it weren't for Microsoft, we would all be out of jobs"

Virus vendors eh?

[kevb]

Virus venders.. hmmm For just £39.95 a month, you too can recieve the latest virii, trojans and worms directly to your inbox.

I'm being optimistic

[hardcoredreamer]

"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" I will be optimistic that despite the development into a new direction, and the occasional headaches, things will be better in the future. That said, why are people so negative about change? So Microsoft's SP2 broke some programs, at least they finally released it. So we have more than 640K of memory and you had to use a memory manager, at least we got past conventional memory. So at least in theory, there will be less buffer under runs in patched/upgraded systems. Would you prefer they didn't try?

Glad this is being addressed... :P

[TripMaster Monkey]

This will be part of Microsoft's future direction with Data Execution Prevention (DEP)

I feel safer already.

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?

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

Time to buy a new computer again...

[the_skywise]

"Hey, my 3ghz computer is running as slow as a Pentium 1.5ghz... Why is that?"
"Oh that's all the new virus checking that runs the executables before they run to make sure they don't have any viruses in them."

So y'see... Viruses ARE good for the industry!

Re:What is it with the buffer overflows?`

[ThosLives]

I don't even think it's due to not checking pointers and NX bits or anything like that. The problem is the way in which our modern OSs map out the memory. Intel chips have the capability to map segments to be either code or data, and the chip will generate a fault if you try to execute anything in a data segment (inherent NX capability). This is part of the segment descriptors used in all programs. The problem is that, as far as I can tell, Windows maps both the code and data segments to the same logical addresses! This is kind of foolish; it should be possible to simply map these two segments to different areas and be completely transparent to the application. As long as applications are behaved and don't have segment overrides all over the place, this should be just fine. Then, when you try to jump to an address that's in the stack, the processor will trip a general protection fault (because the stack must be in a segment defined as data, well, stack to be precise).

Basically this is just laziness in the Windows architecture that overlaps the code and data segments. Separate these and the problem is solved with no new hardware, minimal application rework, and the like.

Incidentally, my perusal of the setup routines in Linux (well, it was version 1.0, so I don't know if this is still the case) show that it also maps code and data to the same actual addresses, which makes it vulnerable as well.

Sure, you can use "smart" languages and NX bits and stuff like that, but it's all assembly at some level, and the processor manufactures actually built in sufficient protection decades ago when they came up with segmented memory. (PowerPC architecture can also distinguish between code and non-code).

I am always amused at how the memory management community hasn't nipped this one in the bud ages ago when the tools to fix it already exist.

Keeping your developers happy

[Aslan72]

The huge problem with McAfee 8.0i has been figuring out a policy that protects from buffer overruns and keeps your developers happy; I've had to loosen the restrictions for those folks because as you put together stuff in vstudio and attempt to debug it, McAfee's Buffer Overrun flags it and doesn't allow it to run :(.

--pete

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:What is a Buffer Overflow?

[nudicle]

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

No Execute = snake oil

[ajs318]

Sorry, but the whole "No Execute" thang is aceite de serpiente, as they say in Madrid. Even the much-vaunted {by people who don't understand it, anyway} Harvard Architecture {i.e. using separate buses for data and instructions, thereby breaking the Neumann principle totally} doesn't work. If the computer can make some kind of decision based on the content of memory location x, then this is tantamount to x being an executable location.

Now, if you had a "Take no action whatsoever based on the content of this location, in fact, whenever you are asked even to read it, always return the same value" flag -- that might prevent the execution of unwanted code. Chances are your system would also be computationally incomplete.

As it stands, NX is trivially defeated by persuading the user to install a simple piece of code -- effectively an emulator.

Basically, NX is answering the wrong question. The question that needs to be asked is "How can we best persuade users not to run arbitrary code when they don't know what the hell it does?" My own answer would be for every processor to have its own, unique instruction set; so only code compiled for that one particular individual processor would ever run on it. {Obviously you'd have to have a compatibility mode for bootstrapping, so you could compile the compiler to compile the unique-ified software; but this would have to be accessed by some deliberate hardware action that no software could get around.} I'm sure that is not impossible; but I'm not sure that it's feasible as long as the likes of Microsoft want to do things their way.

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