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?"
This might be a good test for the outsourcing model, as well. Will the software vendors who ahve outsourced fare better, or worse than those who have kept their support services based here? Might be an interesting thing for someone to watch.
The eternal struggle of good vs. evil begins within one's self.
I'm just a microcontroller guy, but can't the PC guys check their goddamn counters and pointers when using buffers? 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?
"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?
I know a guy named Sig.
With respect, this is complete rubbish.
You can't blame a programming language for sloppy coding. Sloppy code is sloppy code and it makes no difference what language you use, if you're a crap coder then you are going to have problems.
And stating that "C is probably still the language of choice, but the number of people who do that is pretty limited" is just plain wrong. Back in the REAL world, C is used more now than it has ever been.
And besides, what do you suggest you write an OS is ? Perl ? TCL ? Vusual Basic ?
Oh hang on though, surely the Perl interpreter is written in C isn;t it ? Oh, and TCL's ? And Vidual Basic's ? Or is that C++ ?
As I said, back in the real world....
Sure, you can have your code and data in separate spaces if you want. Atmel will sell you a very nice computer that works that way. Of course, you need to reprogram it externally if you want to run something different on it. The notion of running different programs without something external replacing the program memory doesn't work on a Harvard architecture.
And a Harvard architecture doesn't help, anyway, if your program contains routines that an attacker would like to run with chosen data, because the stack, which holds the return address of the current function, must be data memory. So the attacker can replace the return address with the address of the target function, arrange arguments appropriately, and return. The security advantages of a Harvard architecture does have are available already, with MMU flags which prevent instruction fetch from reading non-code pages; the issue is not treating code as data, but treating data as code (without some code telling the MMU that the pages should be code).
A more significant security improvement is disallowing pointers into the stack, and modifying it only with special stack instructions with constant offsets from the top of the stack. This forces people to put their buffers in heap, where overflows are much harder to exploit. (See, for example, the JVM.)
everyone loves to bash MS here, fair enough. i dont really give two monkeys.
however, i just dont think this is true. i run NAV2004 on my XP box, and it never ever flags anything. now, either this means its just cack (corporate edition is certainly pretty cack), or i just dont get all these viruses. i spend plenty of time surfing around the shady underbelly of the web, with firefox admittedly, and i use my common sense with the email i get, however i havent had a virus in 7 years of varying MS systems.
are you sure this isnt just anti-MS hysteria?
Wow, even the non-technical explanations of a buffer overflow are still too technical. I love Shashdot. :)
Buffer = an empty bucket (of a fixed size)
Data = water
Overflow = filling the bucket with too much water
If you're going to fill the bucket up with water, you usually know when to stop. But what happens when you put too much water into the bucket?
It spills.. all over the place. And while you may know that once the water overflows you're going to get wet, if you do this enough times you gain a better understanding of what's going to happen to all that spilt water, and how to manipulate it.
This translates into being able to trick computer programs into basically doing anything.
It seems really silly and dangerous to mix code and data stacks. Why is it so common?
Maybe it will slow down CPUs, but I think that if a CPU knows that a stack will ONLY ever contain return addresses and another stack only contains data there can be a fair number of optimizations.
If you want to really be paranoid, have 3 stacks. One stack for code (return addresses), one stack for data (variables), and one stack for metadata - e.g. each entry could store the end location of the data (e.g. the data stack pointer before a subroutine call).
The popular method just seems really sloppy and error prone.
compilers already do this.
the problem is not jmp to data segments. the problem largely is executable stacks. which is exactly what stack smashing is about.
the other problem is that executable stacks are required for some legitimate compiler functions such as trampolines.
the real solutions are:
_complete_ separation of code and data segments.
code is _never_ writable, under any circumstances.
data is _never_ executable, under any circumstances.
no executable stack.
no more mprotect().
this will solve the arbitrary executable code issue, but won't solve other issues such as logic/sql/scripting exploits. it should solve most of the rootshell exploits though.