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

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"

What is a Buffer Overflow?

[lecithin]

I hate to ask, but as a person that has never been into 'code', I have never understood what a buffer overflow was.

I am asking as a person that isn't a programmer but understands the concepts that go behind the smoke and mirrors.

Re:What is a Buffer Overflow?

[weicco]

Here is really, really simple example how NOT TO WRITE YOUR FRICKING CODE:

char buffer[100];
bool userIsAllowedToDoAnythingHeLikes = false;

gets(buffer);
if (userIsAllowedToDoAnythingHeLikes) {
gets(buffer);
system(buffer);
}

No when user writes 101 bytes to buffer that boolean value is overwritten and it isn't false anymore. Proper way would be to replace that gets function with fread and make sure that user can't write anything over 100 bytes.

Re:What is a Buffer Overflow?

[ayn0r]

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.

Dude, you're making it sound like it's a matter of faith whether stack/heap overflows can be done at all. :-)
Noone said it's easy and quickly done to write a working exploit. It takes time to find the vulnerabilities, and still much more time to write code exploiting them.

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.

Not at all unlikely if you take advantage of offsets that already exist within the program. As soon as you've successfully determined where in memory the program data resides, you can use it as an offset simply put. You bring up a good point though, because this is one common misconception about exploits. A good portable exploit has to take use of memory offsets to work properly.

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?

This isn't limited to Windows. AFAIK all common OS:es share these problems. Now I haven't checked up on these CPU features you're talking about but it's nothing I've ever heard of...

For further reading I recommend "The Shellcoder's Handbook" by Jack Koziol and a bunch of others. It explains the basics on finding security holes and exploiting/securing them, and delves a bit deeper in a bunch of areas as well. Excellent read.

Re:great news

[JeanBaptiste]

question. this is _not_ a troll.

So MS is pushing for (what I'm guessing is) some sort of protection for application layer buffer overflows.

Does linux have any sort of thing like this? I know microsoft doesn't hold a monopoly on buffer overflows ;)

Seriously, I'm curious. Thanks.

Looks like...

[eno2001]

Microsoft and Intel are finally catching up to where DEC was back in 1992. DEC Alpha + OpenVMS = no such thing as a buffer overflow and 64 bit processing as well. Whatever happened to the future again? ;P

A Flawed Architecture

[nurb432]

The basic architecture is fundamentally flawed in today's 'consumer grade' computers. Using a strict Harvard architecture, where data is *separate* from code, would eliminate a lot of today's troubles.

Is it too late to change? Well, we have had new chips arise ( like power , or CELL ) so, its not impossible.. just difficult.

Strengths and differences of this vs SELinux

[weave]

I just got done reading an interesting article about SELinux. I'm just curious as to the strengths and weaknesses of each approach.

The SELinux approach sounds to me like a far better way to approach this, actually controlling the permissions of a process with some high degree of precision, down to what files it can use and what other processes it can invoke.

Anyone learned in this stuff care to give a non-flamed opinion of the two approaches strengths and weaknesses? Also, do or will the newer Linux kernels do anything similar regarding stack protection?

Re:Strengths and differences of this vs SELinux

[Anonymous Coward]

SELinux is about MAC (Mandatory Access Control). Its much more strategic and works as a last line of defence. DEC is about protection from buffer-overflows. This is more of a tactical approach to protect a system from certain kinds of memory exploitation attacks. It only protects you on a narrow field out of a spectrum of possible attack methods.

You probably mean PaX vs DEC vs ExecShield

Re:Strengths and differences of this vs SELinux

[kbielefe]

This is a good introduction to the main solutions to software exploits in Linux and the different kinds of protection they provide and why.

Most people recommend a combined approach including mandatory access control, chroot jails for services on the internet, stack smash protection, address space layout randomization, non-executable memory pages, firewalls, virus and spyware scanning, intrusion detection, regular vulnerability patching, and user education (did I leave anything out?). No one will tell you that you are safe after implementing just one of these solutions, but the more you do implement, the more secure your system will be.

All of the above have been available on Linux for some time, but are not implemented by default in any popular distribution that I am aware of, which is a shame because I believe it is only a matter of time before someone writes a really nasty worm for Linux. Most Linux users I know seem to believe they are safe with only regular patching and a firewall.

Gentoo is the best distro I have found for implementing these security measures and tries to build them in as an option wherever possible. Gentoo has great documentation on security and is all about custom configuration and compiling. Since some of the above solutions require special compiler technologies, Gentoo is a perfect fit.

Each of those solutions take a certain amount of effort to implement and will break certain existing applications in different ways. Basically, Microsoft is taking the next step and implementing the least disruptive and easiest solution that will provide some protection for all software running on the system. They should probably also compile their own software with stack smash protection and make address space layout randomization available as a next step.

Software for software

[Doc Ruby]

Compilers should store data in separate protected memory segments, never embedded inside code, where overwrites can change adjacent instructions. JMPs to data segments should issue compiler warnings, and execution past original allocations should set a flag, at least in the VM. The compiler and existing VM can protect from most overflows, and is a centralized link in the chain to guard the software from every programmer, no matter how naive. If CPU vendors want to get on the bandwagon, they can offer an interrupt triggered by such boundary transgressions. Making buffer execution the exception, requiring handling, rather than the default, is a better model of coding suited best to the compilers that translate our directions to the computer into instructions to the CPU.

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

People Still Writing Code in C

[billstewart]

C is one of the best languages out there for many things, but nobody should still be using it, because there are too many people who are careless about subtle things and shoot themselves in the foot with it. Yes, if you're writing device drivers, C is probably still the language of choice, but the number of people who do that is pretty limited, and they can run lint and doublecheck their code to make sure they don't get overrun errors. C++ isn't much better - you _can_ write code using constructs that don't get buffer overflows, but you don't have to (if anything, the nicest thing about C++ is being able to fall back to C when you need it), so a random C++ program is no more trustable than a random C program. It's not the 20th century any more - stop doing dangerous things!

(And yes, I still write C/C++ when I need it, but that's laziness after 25 years of habitual use, and usually I use shel when I need to program :-)

Re:Umm...

[dhbiker]

so am I right in thinking this tool would slow things down slightly and up memory usage slightly as well? Or would the performance change be negligible?

Ps whoever modded my original comment as a troll is an an asshole, it was not a troll but in fact a genuine question. But then you'll probably mod this comment as a troll anyways even though I genuinely want to know a bit more about these tools, go ahead mod away!

A Tough Transition

[cyngus]

Having recently gotten my hands on a Windows XP box with a P4 that supported the NX bit I thought I'd turn it on, good idea right? yeah, great idea if you don't want to use half your applications. The NX bit stayed used for about five minutes. I wonder how many of Microsoft's apps will actually work with this protection turned on.

Boldly going where Linux went back in 2000

[mccrew]

Sounds like folks are reinventing Avaya Labs' incredibly useful Libsafe. This is a library that you can set up to preload before libc, either on a process-by-process or system wide basis, and it defines its own set of functions (strcpy, et al) to override those in the standard C library. It is able to detect many stack smashing attacks. When a stack smashing attack is detected, the offending process is terminated, and the administrator is sent an e-mail with copious technical detail.

I am surprised that major distributions have not picked up and run with this great tool. One of the first things I do on any new machine is to ensure that all internet-facing services are being run with libsafe preloaded.

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.

DEP has nothing

[bluefoxlucid]

DEP actually can be evaded because it supplies no ASLR. If the attacker can reasonably know where some data exists in memory--particularly, his exploit and msvcrt.dll for memcpy() and VirtualAlloc()--he can basically switch DEP off during an attack. Believe it or not, this is pretty easy if everything is in the same place every program run.

Fortunately in Linux we have PaX, which supplies much better protection than W^X, Exec Shield, or DEP with "competetive" (i.e. comparable, potentially lower; it can actually viably compete) compatibility. Red Hat of course has convinced the GCC devs to make GCC mark everything to have an executable stack if the compiler is at all not sure that it can operate without one; but PaX ignores that and still only "breaks" a few packages (and nVidia's glx).

PaX, GrSecurity, IBM's SSP (ProPolice), and PIE executable binaries should pave the future on Linux; but people are trying so hard to avoid them. It's not even much work to maintain a distro using those.

DEP is basically like vanilla Linux on AMD64.

Lets see...

[Anonymous Coward]

will software vendors be able to keep up with the support calls?
---
It would be better if the vendors fixed their buffer overflows and avoided the support calls. It's too bad the users will be caught in the middle, but Microsoft is doing the right thing.

Lets weigh the choices:
1. Leave the security issues in place for the convenience of the users:
Russian card mob gets all of your info because a program, active x control or something else exploits an unchecked buffer.

2. Inconvenience the users and secure their computers better:
Half the software they have stops working because it's written insecurely, but their bank account doesn't get drained. User has to wait for patches from vendor to use programs.

I'll take inconvenience over mortgage forclosure (due to drained checking account) and bankruptcy any day of the week.

This will most likely force vendors to properly check their buffers and write more secure software.

l8,
AC

Segmentation is better! (not)

[Anonymous Coward]

You obviously don't remember how painful it was to program for 16-bit Windows. Segments and thunks and far pointers and all that other bullshit.

Windows uses a 4GB flat address space. The same memory model used by Linux and all other modern OSes. Segmentation, though supported by the hardware, is (1) inefficient and (2) more difficult to program for. Even CPU vendors realize it was bad technology and are moving away from it. Example: The new AMD64 chips support all the segmentation crap in compatibility mode, but if you switch them to 64-bit mode they ONLY SUPPORT A FLAT ADDRESS SPACE. There is a word for this: "Progress".

The real answer, as another poster pointed out, is to add NX bits to the page protection hardware. One of the odd quirks of the x86 page protection hardware was that if you can read it, you can execute it. That turned out to be a bad design. :)

Re:It's an intel flaw

[RaVPup]

Intel and AMD chips have only just added a seperate read and execute bit. Solaris 2.6 first introduced the non_exec_stack parameter and that was defeated using return to libc. The SPARC V9 architecture has had seperate XR bits for a while and return to libc works on that architecture. I think a lot of people are falling for marketing hype.