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?

Re:Virus vendors?

[goombah99]

who buys viruses Perhaps the moderators do.

or maybe this is just the new term for microsoft?

Re:Virus vendors?

[King Of Chat]

Ah. OK. Change the story so as to make me look retarded then mod both my comments down. Carry on.

Re:Virus vendors?

[PoopJuggler]

Here comes the next $multibillion garage startup: www.vbay.com

Re:Virus vendors?

[DarkMantle]

Apparently alot of people do. I get alot of calls at work with people asking about their "Anit-Norton-Virus" that they bought at the store.

You heard it here first.

Re:Virus vendors?

[Arctic Dragon]

McAfee Virus Admin users, of course.

Re:Virus vendors?

[monkey_jam]

an auction site for virgins?

Re:Virus vendors?

[BorgCopyeditor]

I hope they don't have it on the same hard drive as their Norton Virus; if those two come into contact ... it would be bad.

Re:Virus vendors?

[binner1]

Why would anyone pay for viruses? I just download mine for free off the internet with this nifty new program I found!

-Ben

Re:Virus vendors?

[PoopJuggler]

You may have something there

Re:Virus vendors?

[cd_serek]

Where there is a supply - there is a demand.

Huh......

[Querty]

virus vendors... ???

Re:Huh......

[penguinoid]

I'm an anti-(virus vendor).

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"

Re:support calls

[dioscaido]

I definitely envy my linux/mac IT friends, who come in at noon and leave at 2! I do remember that time back in 1994 when there was that one bug in the linux kernel which required a patch.

Re:support calls

[SgtChaireBourne]

The jobs would still be there, it's just that instead of putting out Bill's fires, you'd be using your computers to improve service or make new services.

virus vendors?

[2020hindsight]

Virus vendors have been pushing buffer overflows for quite some time ...

Outsourcing

[Datamonstar]

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.

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.

Re:Virus vendors eh?

[RaguMS]

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

What a ripoff... I get all of mine for free.

Re:Virus vendors eh?

[atomic_toaster]

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

The companies charging for viruses would eventually go out of business to the companies that provide better viruses for free and only charge for tech support...

Re:Virus vendors eh?

[dfiguero]

Nah!

I get my pirated copies for free from my friends!

Re:Virus vendors eh?

[penguinoid]

Please, do not pirate closed source viruses. Instead, use open source viruses, which you can get for free.

Re:Virus vendors eh?

[pizzaman100]

Can anyone recommend a good free antivirus software?

Re:Virus vendors eh?

[kyhwana]

http://www.grisoft.com 's AVG works pretty well and has a free edition.

Re:Virus vendors eh?

[mmontour]

Try ClamAV.

What is it with the buffer overflows?`

[Anonymous Coward]

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?

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.

Re:What is it with the buffer overflows?`

[darkain]

another flaw of modern software is race conditions when working with multiple threads.

lets say you have a global pointer to an object... in thread A, you are deleting an instance of the object, then the OS jumps threads in the middle of this operation, and thread B goes and tries to access information from the same object. this is known as a race condition.

basically, which one gets their first, and how much damage will it do? the more you start working with shared memory and threads, the more code protection has to go into place. its simply not as easy as it used to be to write a solid application, because more is going on.

Re:What is it with the buffer overflows?`

[uberdave]

Stuffing a buffer past its end is poor coding no matter how you slice it.

Re:What is it with the buffer overflows?`

[ThosLives]

I agree with this, but my point was that the exotic methods the big software houses are proposing are unnecessary. My sentiments are pretty much those of the AC who also replied to you: not checking for overflows and stuff is naive. But, again, perhaps that's because I too am involved with safety-critical embedded systems (I develop engine controllers) and we have to make sure that we account for things that should never happen (i.e., always put a default in a switch block that recovers even if the only expected values are covered in explicit cases - if the internal state machine gets corrupted, we have to try and compensate).

But seriously, how hard is it to put an "if index is greater than limit..." check in your code? I don't know. I've never thought it all that difficult a concept.

Re:What is it with the buffer overflows?`

[Swamii]

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.

Re:What is it with the buffer overflows?`

[rcamera]

this is where the concept of a mutex comes into play. you use globals in threaded apps without a mutex? remind me not to hire you any time soon...

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.

Re:What is it with the buffer overflows?`

[v01d]

Oh, just admit your daddy won't let you visit this site if he sees all the cursing...

Re:What is it with the buffer overflows?`

[Anonymous Coward]

"We try our best, but we're humans. We make mistakes."

You've been making the same mistakes for over three decades now. Some might put it politely thus: some are more human than others....

Re:What is it with the buffer overflows?`

[Bob 4knee]

The stack is often (with good reason) used to pass parameters to a subroutine (function, what have you). It is also used to hold the return address. The problem with a buffer overflow attack is not "jumping to an address that's in the stack", it's when a setuid program allows an unprivileged user to overrun a parameter (on the stack) and write over the return address. The OS then "returns" to the bogus address, and runs code the user selected BUT with more privileges. Good coding practice will fix it (don't write to location 12 of a 5 byte vector). Even if the coders aren't being careful, there are ways to fix it (google for "stackguard", for example).

Re:What is it with the buffer overflows?`

[nogginthenog]

It's all very well knowing what your code is doing but what if you are using a non open source 3rd party library? There could even be buffer overflow bugs in your C runtime, or as we recently saw in (IIRC) libPNG.

Re:What is it with the buffer overflows?`

[sapgau]

Well apparently many other programmers that do these things have been hired and so we have these problems including at the OS level!

Parent post explained it concisely, no need to top it off with the latest sarcastic slashdot cliche.

Bah!

Re:What is it with the buffer overflows?`

[m50d]

Now, sitting here, it's easy. But at 5am a week after the product was meant to ship, things like that tend to take a back seat to getting the coding done.

Re:What is it with the buffer overflows?`

[Nevo]

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!

Re:What is it with the buffer overflows?`

[pchan-]

My God, who modded you up? That was, perhaps, the least factually correct post I've ever read on Slashdot (even including the troll reports of Stephen King's death).

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.

This is true for Linux, FreeBSD, NetBSD, and BeOS. In fact, OpenBSD is the only OS I know of for x86 that does make use of the execution segment division (only recently implemented), and they freely admit that their implementation is only a halfassed solution to the problem. The reality is that this is not a trivial problem. x86 processors only provide a single "line" in the memory which separates instructions and data (unlike AMD64's per-page execute permission bits). With dynamic linking, mmap, and shared memory, this becomes very messy. The OpenBSD implementation broke many applications which execute stack data. Particularly, gcc tends to produce code that executes stack data when it encounters anonymous functions in C (so any program using anonymous functions can potentially have explicit stack execution coded in).

As long as applications are behaved and don't have segment overrides all over the place, this should be just fine.

This is utter nonesense. No 32bit windows program uses the segmented memory model. As another poster pointed out, they all use the flat 4gig memory model.

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

Jump to an address in the stack, you mean like returning from a function call? Or calling a function pointer? Or in some cases calling a method of a class? Again, nonesense.

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

No, the NX bits on Alpha, Sparc, and now AMD64 processors are at the _hardware_ level, and they do not require segmented memory. There are software-level solutions, but they are beyond the scope of this discussion. The PowerPC code segmentation is as bad as the x86 model, and equally painful. MacOS X does not segment its memory space either!

Re:What is it with the buffer overflows?`

[Nefarious Wheel]

How difficult would it be for an x86 chip vendor to build in support for layered memory protection a/la VMS? Something that would support the separation of address space between privileged and nonprivileged executable areas? The old Vax had it - you were never in a position where you could modify the system kernel or a device driver from a program running in user mode without heavy, explicit permissions. If you tried to execute code from data, any data, forget it -- the instructions just wouldn't execute in that address space. Granted those machines blew up for other reasons, but they were secure. Close cooperation between O/S and CPU designers used to be the rule.

It seems that software people always look to a software solution, and never blame the invisible hardware. What is the extent of the communication between MS and Intel? Is there a (be polite folks) hardware solution to the O/S security question?

Will software vendors be able to keep up?

[TheBrakShow]

"Will software vendors be able to keep up with the support calls?" No. Customers are going to have to wait on hold for... Oh... Nevermind.

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?

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?

[Anonymous Coward]

Wikipedia to the rescue

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

[TripMaster Monkey]

Great explanation of buffer overflows here

Re:What is a Buffer Overflow?

[coolcold]

another more "realistic" explaination

consider your brain as buffer.
You did something wrong and your wife starts to "educate" you for hours, with alot of "common senses"
You then sort of half listening since your brain (buffer) can't accept that much information at one time
In the end, you will only remember what she said for the last 30 seconds throwing everything in the past hours into the void---this is called buffer overrun

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

[3.2.3]

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?

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?

[LarsWestergren]

Yep, pretty good explanation. It's pretty hard to catch all of them if you are using a language susceptible to this problem.

When I was subscribing to bugtrack I read about people who had found a security problem in a simple game written in C included in many Linux distros. The overflow? Second player name. :-)

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

[Bruce Perens]

Look up the "solar designer" patch for Linux, included in some versions of secure Linux. It uses a segment to address the stack, and manages to execute-protect it, even though the processor is running in page mode and does not have an execute permission bit in its page-table implementation. IMO Microsoft could use this and does not. But Linus has objected to it as ugly and insufficient and won't accept it into his own sources.

The basic problem is that Intel didn't include an execute protection bit in the i386 page-table implementation and was incredibly late to add one, even though there was a spare field in the page-table-entry that could have been used. We had this in the VAX in 1981, in other processors before that time. Linux has taken advantage of it, where it exists, for more than a decade, Unix since the 1970's.

Bruce

Re:What is a Buffer Overflow?

[Blakey Rat]

Words or phrases you used that a non-programmer probably does not understand well:

* Subroutine
* Return Address
* Stack
* Local Variables
* Jumps
* Array
* String
* Push
* Allocated

Thank you and goodnight.

Re:What is a Buffer Overflow?

[Exocet]

Bruce,

In all sincerity - why reject something as "ugly" ...and do, seemingly, nothing at all? That's my perception, anyway. It's not like patching the kernel requires that you use the OW patch stuff. But for everyone that cares about "more" security... wouldn't this be a good idea?

Re:What is a Buffer Overflow?

[Bruce Perens]

I agree with you in this case. But I haven't looked at all of the implications of the patch. It may also be that some distributions ship with this as standard. Red Hat might, but I've not confirmed it.

I believe that the current best practice is to have a bit in the header that enables the patch on a per-executable basis. It used to be that signal trampolines (used to switch stacks when calling an asynchronous signal handler) broke, as they actually built some executable code on the stack. But this may no longer be true.

Bruce

Re:What is a Buffer Overflow?

[sumbry]

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.

Re:What is a Buffer Overflow?

[TheLink]

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.

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.

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.

Re:Glad this is being addressed... :P

[leuk_he]

What makes this old news.

By the way, notice that macafee never call it DEP, but use their own marketing talk for it. If i just figured out what this virusscanning software did. (I t does not block spyware, that is for sure)

Re:Glad this is being addressed... :P

[jd]

Hey, Microsoft has already milked the "Binary Execution Prevention" market.

Re:Glad this is being addressed... :P

[jd]

Hmmm. It's just occured to me that this new feature is named after the actor who plays a rather nasty pirate.

Exploits can be pure data

[redelm]

Malware doesn't need to bring in code, there's plenty of code in the target executable. All it needs is to be able to grab control via the return address on the stack. Then fill the stack with exploit data and set the return addr to something like an exec() syscall.

CSA already does this

[wschalle]

Cisco Systems CSA product does this and more.

Data execution is immoral

[Anonymous Coward]

Regardless of how you feel about data crimes, it is not moral for capital punishment to be applied to data, regardless of the heinessness of the alleged crime.

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

Re:Looks like...

[Florian Weimer]

DEC Alpha + OpenVMS = no such thing as a buffer overflow and 64 bit processing as well.

DEC ported the Microsoft DCOM implementation from Windows to OpenVMS, including its buffer overflow bugs.

Re:Looks like...

[gabba_gabba_hey]

fair enough for the most part, but:

These people are evil even by atheist standards ...

Seriously, WTF? Explain to me how atheists are inherently less moral than people who believe in some magical fairy that tells them it is ok to commit genocide against people who believe in some other magical fairy let alone all the other atrocities that are perpetrated in the name of "faith"?

I know I shouldn't respond to the troll but if you are serious, you need to get a grip.

Well that and the fact that the current computing environment necessitates that some people be involved in security in order to attempt to plug the holes left by the awful platforms that we are stuck with. That said, I wholeheartedly endorse something better and you are absolutely right to be furious that security design principles that have existed for decades are unused by the current crop of mainstream OS/architecture combos.

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:Not a silver bullet

[PhrostyMcByte]

No,

Visual C++.NET 2003 has a compile switch that makes your app check the return address, so that is nothing new. DEP interacts with the NX bit on the CPU to stop data-only memory from being executed, which should prevent a lot of buffer overflows.

Nope

[bigattichouse]

If they are a small user (grandmom), they will box the damn thing up and go back to reading the paper and playing bingo at the VFW.

Eventually, someone will create a ROM-booted web applicance that has flash and pdf capability built in that they will feel comfortable using, will work for 10 years without an upgrade, and is immune to viruses because when you turn it off - everything is wiped. Their "Desktop" will be on google or somewhere external to their own system.

Re:Nope

[hh1000]

Knoppix Linux ...

Re:Nope

[Animats]

That's been done. It was called the "I-Opener. Worked fine. Booted from non-volatile memory. Ran QNX. Microsoft killed it by making IE incompatible and took over the browser market.

You could redo the I-Opener today. In fact, you could even get the latest version of QNX with the new embedded browser and load it into an I-Opener.

Something like that should be in every hotel room, where you really want a stateless client machine.

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.

Re:A Flawed Architecture

[geekee]

That's exactly what's happening. When a buffer overflow is executed, the processors throws up a red flag saying, this is suspicious, you're trying to execute code sitting in the data cache instead of the instruction cache.

Re:A Flawed Architecture

[Josh Booth]

Using an executable bit for memory pages, you have no executable problem. If you use a strict Harvard arch, then you lose the huge flexability that comes with using one memory. What if you run out of data memory but have huge amounts of code memory left? Someone will inevitably create a swapping module move memory from one type of memory to another, nullifying any benefit from a Harvard architecture. Modern processors do split their L1 cache into code and data anyway, already taking advantage of the extra speed that comes with the Harvard architecture.

Re:A Flawed Architecture

[iabervon]

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

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

[dhbiker]

I gotta admit I'm a bit fuzzy on this but here goes:

I think that it basically boils down to the way the two OS's are written (or their architecture). The original windows was not concieved in the same manner as *NIX, file permissions etc did not even properly exist (as far as I know, but I could be wrong) in Windows until fairly recently

I think the the SELinux approach is a better one, mainly because it seems to tackle the problem before it happens rather than being a reactive response to a compromise. However I doubt this approach is even possible in windows so they are trying to make the best of it.

Just my 2 Cents

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

[demaria]

Such functions have been available for years on Windows and Unix, such as the Cisco security agent (formly Okena). When properly configured, you can run a Windows system without apply a patch for a whole year and not get exploited (which is very hard to set up).

The problem is that administrating these permissions is a real pain in the ass. It's not simple at all, and is usually more of a hassle than its worth. Different version of the same product may require different rule sets. Even a simple, small patch can break existing rules. Usually these products are destined for servers in static environments.

Re:Strengths and differences of this vs SELinux

[demaria]

File permissions were introduced with the NT line, so they've been around for many years. W2K and XP come from the NT branch. NT file permissions are also superior (in design) to the standard Unix permissions.

Re:Strengths and differences of this vs SELinux

[kbielefe]

Actually, systems like SELinux are specifically designed to limit the abilities of even the root user according to the situation, making a "root exploit" much less effective in most circumstances unless it is an exploit in the kernel itself, which is a lot more rare than an exploit in a daemon.

Re:Strengths and differences of this vs SELinux

[dhbiker]

since you seem to know a lot more about this that me could you explain the differences between the two?

I've only limited experience with both (unix and windows that is) and as far as I could tell the windows implementation was the same as the Unix one (I gotta admit I've only really used chown and chmod, so as far as I can see they're the same, since you have an owner and a set of three permissions under Unix and WINNT)

Re:Strengths and differences of this vs SELinux

[chrisopherpace]

With NTFS permissions, you can set group permissions to an object, as well as multiple user settings. For instance, Bob and Jill are both in group Secretaries:




Bob: rwx
Jill: -wx
Secretaries: r-x
Everybody: ---



This set of permissions cannot be done in Unix/Linux, without using another solution other than FS permissions. In addition, NTFS permissions are more detailed and complex than RWX, you have:

Change Owner/Permissions of Object
Execute and View Directory are Seperate permissions
and Read Permissions of Object

Which UNIX/Linux does not have natively. I believe you can achieve the same thing (except for the special permissions) using SELinux.

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.

Re:Strengths and differences of this vs SELinux

[weave]

We're not talking about file permissions (er, I don't think) but process permissions.

File permissions are permissions granted to a user. This is permissions to various objects and resources granted to programs and processes.

Big difference.

As an example, the author of that Redhat article has a Fedora Core 3 box set up with a very restrictive SELinix configuration and freely gives out the root password and even with root, people can't do anything dangerous to the box.

He's had a similar Debian box out there for two years now and no one has hacked it, even though they already have root and a shell!

Re:Strengths and differences of this vs SELinux

[weave]

Right, the author of that SELinux article has a play machine where he gives out the root password and dares anyone to hack it.

You have a root shell but can't hack the box. That's pretty impressive.

I disagree.

[AtariAmarok]

Sometimes, serious crimes such as participating in the films "Star Trek 9" and "Star Trek 10" need serious punishment. Data is indeed guilty.

Re:great news

[King Of Chat]

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.

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:Time to buy a new computer again...

[ceeam]

You are kidding but I bet that AV software led to more moneys spend/wasted on "customer" side than all the viruses combined. Still it does not protect you (I mean - your average PC user) from majority of threats.

Re:Time to buy a new computer again...

[danheretic]

"Hey, my 3ghz computer is running as slow as a Pentium 1.5ghz... Why is that?"

It's because you bought a computer from Dell, Compaq, IBM or any number of vendors who bundle vast amounts of memory-resident crap on their already-crappy bargain-basement hardware with half the RAM it should have.

Re:Time to buy a new computer again...

[m50d]

You got half? Lucky bastard. I have seen, no joke, a 3GHz Dell sold with 64mb of ram.

DEP is already in Windows

[hkb]

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.

Re:DEP is already in Windows

[davez0r]

W2K3 SP! also includes a...

is that Microsoft Plus! for win2k3 server?

Re:Umm...

[mchawi]

You're assuming that all buffer overflow issues are theirs. Although they are known for that issue - there are also many 3rd party programs that do this as well. So they SHOULD be responsible for fixing their own bugs, but they're also going the extra step to hopefully protect against people using other buggy software.

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:Software for software

[Doc Ruby]

No - praising the compiler. I trust the compiler to beat the best microcoders at Intel and IBM - how is that "blame", AC?

Re:Software for software

[bani]

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.

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:great news

[rockinrobotix]

I think the main protection linux has is alot of critical eyes thinking of things like buffer overflows. Or at least thats what I'd like to think.

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.

Congrats!

[Silver Sloth]

If you're not a techie that's a very concise, understandable, and accurate answer. I'd mod if I had the points

Don't mean to bash MS, but

[slobber]

Stack overflow protection has been available in Linux for ages. I believe it is one of the standard kernel build options starting 2.4... Welcome to 21st century, Microsoft!

Re:great news

[TripMaster Monkey]

The main protection Linux has is the developers looking at Microsoft and saying, "See those guys? Let's not be like those guys."

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.

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:People Still Writing Code in C

[Anonymous Coward]

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

Re:People Still Writing Code in C

[m50d]

You are right but for the wrong reasons. The fact is Perl (your example, not mine) would do fine for the majority of programming. Yes, the OS and the interpreter have to be in C or C++. But those should not be the majority of the programming; the OS is meant to serve the applications, not the other way around.

And there is a working Java OS knocking around somewhere. A little assembly stub to get the boot going, then it's all Java. Sure, you can have errors in that stub, but that's not much of the code, and you can restrict it to the best coders.

If you are a bad coder you will have problems. But you will have less problems in a language where mistakes are harder to make. And what if you're a good coder? Even the best make mistakes occasionally, and in C they are more likely to be fatal.

I think a good analogy is live wires. Every halfway competent electrician can work with live wires without killing himself. But every halfway competent electrician will avoid working on a live wire whenever he can.

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.

Less of an issue if...

[KiltedKnight]

... users didn't have to be members of the Administrator group. Then the system files would be somewhat more protected in that the user wouldn't have write privileges. I'm not saying the issue goes away entirely... just that unless what you are running requires some kind of administrator/superuser privileges, you can contain damage to the process at hand.

You are quite right, however, in that buffer overflow is a result of careless programming. Making assumptions about length of strings is fine if you're in a purely academic setting and under time constratints to get your programming assignments done... besides, your professors usually will tell you that it's fine. I do wish, however, they'd emphasize that while it's fine in a controlled environment, in the real world, you have to provide for checks against buffer lengths, etc.

C is still used for a lot of things because of its flexibility. Yes, you can very easily shoot yourself in the foot, but with the flexibility and power comes greater responsibility... which means anyone who uses it needs to be vigilant, always expecting the unexpected.

Well, it's just the rise of "Worse is Better"

[PHAEDRU5]

Check it: http://www.jwz.org/doc/worse-is-better.html/

What this really implies is that the world will always be playing catch-up with the virus writers: security is only an issue when someone releases an actual threat. Until then, there's no economic incentive to do anything about it.

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!

Re:great news

[ColdGrits]

It's built-in to OpenBSD and has been since V3.3 (currently shipping 3.6, 3.7 due in 2 months).

Great News?

[ackthpt]

This is good news everyone, it is good to see mircosoft caring more. Thanks for your time.

Yeah. I saw the Boost Marketing headline this morning:

Microsoft Hands Out Free Security Posted by Clare Greenway on: Monday 28 February 2005
Healthy Competition at Risk?

I dunno how I feel about competition. I'm not so sure the free security is such a winfall. After all, I've already paid for all the bugs and security holes.

Re:Great News?

[ackthpt]

it is crazy to expect perfection in software even if you paid for it.

No. I'm not crazy for expecting it. Particularly when the profit margin on Windows and Microsoft's other holey products, such as Outlook, certainly underscore the ability to have spent a bit more on Q/A. It has been pointed out that a great many things so flawed would have triggered massive class action suits and recalls. What makes them exempt?

Atleast now micosoft is taking the problems much more seriously now, even though it is because of all the terrible press they have been getting lately.

They should have taken it seriously from the start. Companies like DEC, IBM, Prime, DataGeneral, Sperry, etc. all took such things seriously in the past.

Who buys viruses?

[nlinecomputers]

I thought everyone knew that spammers did. Most all the viruses in the last 2 years or so have been spam pushing bots. Somebody is buying the damn things and someone is selling them.

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.

Re:No Execute = snake oil

[Just Some Guy]

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.

Basically, then, you want to encrypt executables so that they can only run on the CPU they're compiled for.

In other words, you want your code to be Trusted before the CPU could even think about Computing it. By Dicky, that's a Really Meaningful suggestion!

2002 called and wants its universally reviled ideas (and lame jokes) back.

Re:No Execute = snake oil

[peachpuff]

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

How would that help? It would make all software harder to use and waste everyone's time, but it wouldn't make users any more discriminating about what they run. I'd rather have an NX flag that prevents buffer overflow attacks than a processor that responds to them by taking random actions.

Re:No Execute = snake oil

[ajs318]

Basically, then, you want to encrypt executables so that they can only run on the CPU they're compiled for.

In other words, you want your code to be Trusted before the CPU could even think about Computing it. By Dicky, that's a Really Meaningful suggestion!

Yes, that's exactly what I'm saying. After I, or a team of experts acting at my behest, have audited the source code and made a triage decision {use it as it is; use it, but modify it first; or don't use it at all}, then I would compile it; in the course of which it would be tied to my processor using my Private Key. The version I compiled would not work on any other computer, and code compiled by other people would not work on my computer. Well, not unless they had my Private Key, anyway, and you can assume I'm going to be careful with that.

I can change my Private Key anytime; but to do so, I would have to perform some hardware action. If I'm installing software on a whole office full of computers, I'll lay the same key on all of them; but I probably won't install the properly-keyed compiler on any of them.

That way, I know I can trust what my computer is doing; and my rights to choose what software I run and to audit source code before I compile it are managed digitally for me.

Re:No Execute = snake oil

[ajs318]

Compilation is merely translation, and does not solve any problem with finality in the way you suggest NX does not. What can be expressed in one Turing-complete language (your C source code) can be done in another (your CPU machine code), including expoits and hacks. Isn't your CPU, after all, just an "emulator" for the original source code?

I never said compilation by itself solved anything. You're right, it doesn't: you could in theory build a processor which natively executed C instructions, with no need for a compiler or interpreter. Traitionally, instruction sets have always been designed more with speed of execution in mind than with human-readability {though some drum-memory machines from the pre-ASCII days actually had a character set chosen so that certain letters' codes corresponded to the instruction represented by that letter; for instance, the code for "A" meaning "add" might actually indicate the add instruction}.

What I'm talking about, as a way to bypass the protection offered by NX, is an emulator running in execute-enabled space to allow the execution of code marked as non-executable. If your architecture won't allow even this, then it's computationally incomplete. {Does that mean there will necessarily be other gaps in its repertoire? I honestly don't know. If computational incompleteness can be partitioned and isolated, so that the insoluble problems are all ones that you don't need to attempt, then this might well be an acceptable compromise: a "just complete enough" computer. Maybe someone deeper into theory can answer this one.} If a user can be persuaded quietly to install such an application, then any protection afforded by NX is ultimately lost. It needn't even be a full emulator; just a dodgy exception handler which does something fancy when you hit a section of NX code. Now the vulnerability has just become a distributed one. So you might have one piece of malware causing the initial buffer overflow, and triggering off another piece of malware in the NX exception handler. If you decide the NX exception is too serious to allow any software to deal with it, and just stop the computer dead, then you turn an arbitrary code execution vulnerability into a denial-of-service vulnerability.

I've hardly ever looked at the source code for the apps I compile routinely in Gentoo Linux; who's to say that I haven't compiled a rootkit inadvertently?

In theory, not a lot.

In practice, the probability that someone else might have downloaded the same rootkit, noticed it and told someone.

Given how many people have access to the source code of all the stuff in the Gentoo repository vs. how many people have access to the source code of certain Windows applications -- not to mention their motivations -- I know which one I trust more.

There is NO FINAL ANSWER to the problem of security, and there never will be. Just like terrorism, you work around the problems as they arise and keep moving forward.

Indeed.

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.

Re:DEP has nothing

[bloo9298]

From the linked blog post:

This could only be properly protected against by incorporating Address Space Layout Randomization into the protection scheme.

I don't believe that. Using a canary would stop the attack discussed in that post (which is an attack strategy that is already well known).

MS Visual C++ has offered the option of canary protection for some time (even if they did not use Cowan's name for it). I would have expected that SP2 involved recompiling most/all code with the check prior to a return with the option of hardware protection on platforms that support it. Can't say that I have bothered to investigate though.

Re:DEP has nothing

[bluefoxlucid]

Using a canary would, but that requires recompile of the program's source code. Using ASLR does not; it's completely kernel space, which is more interesting than userspace because it provides OS-mandated protection.

Better idea?

[CODiNE]

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.

Re:Better idea?

[WillerZ]

This is already done on many systems. It is usually done for all calls, not just those which are believed safe. Of course, for heap memory the compiler is unlikely to know the size of the buffer at the point of potential overflow, so you would get delayed errors if you tried to check all buffers.

I just use IBM Rational Purify to build a version of my code, chuck random crap at the purified version and fix all the problems it finds. It's relatively expensive, but I think it's worth more than it costs.

Phil

Re:Better idea?

[halleluja]

(...) Then again your overflows still have a 1 in 256 chance of working. ;-) This means that one in 256 targeted users will be affected by a buffer overflow. Considering the spread of worms and virii today this is not acceptable.

Re:Better idea?

[Just Some Guy]

Even better, get rid of these stupid null-terminated strings in favor of a string-length word at the beginning of each string. You can get put me on record as saying that a 2^64-byte string ought to be enough for anybody.

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:great news

[mscnln]

Yep, it does. With the grsecurity patchset, you can disable memory from being executed.

To an extent

[Craig Ringer]

No, the "PC guys" cannot guarantee that every single allocation and buffer access in a 100,000 line program is done correctly. Hell, the "PC guys" find it very hard just to make the program work at all.

I'm one of said guys, so I'm well and truly familiar with this pain.

Part of it is culture - features and fast development above correctness. A project I'm involved with now is a horrifying mass of spaghetti that barely works at all, yet they're still adding new features with little focus on cleanup. There is no test suite.

As for libraries, etc ... not really, no. Nothing universal, anyway. Higher level toolkits do help a lot though.

IMO the part of the solution is use a language better suited to writing software on the scale we do it on PCs. Not C, suitable for OS kernels and microcontrollers, or C++, but something with AUTOMATIC MEMORY MANAGEMENT. No more (programmer-visible) buffer manipulation, no more pointer ownership problems, double free()s, and forgotten `delete's.

Use of tools like valgrind is also important, as is coding carefully and considering getting it right as more important than getting it "working".

Finally, though it's not as useful for security issues, test suites are a really important thing in software development IMO.

Re:great news

[Anonymous Coward]

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.

Hal

[tommyth]

So, how many people had this thought pop into your mind when you read this post:

"I'm sorry Dave... I can't let you do that."

Or has that been said dozens of times? I haven't read the comments.

Orthogonal

[Craig Ringer]

The two approaches are orthogonal and can be combined. For example, Red Hat FC3 has both SELinux and ExecShield (which includes library address randomisation and W^X-style checks like what MS calls "data execution protection").

Re:Time to change.... OS

[kyojin the clown]

you need to run huge globs of anti-virus software just to stop it being compromised

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?

This is stupid

[Pig Hogger]

This is totally stupid.

Why not instead push BETTER PROGRAMMING, if needed by the total eradication of the programming languages that happily let you shoot yourselves in the foot by letting you program sloppily?

Also, castration of programmers could help by reducing the need to display machoness by programming in a low-level language (or what looks like a high-level language but is in reality a disguised assembler) could be contemplated.

But, of course, nothing would beat a major clueing-in of programming -spit- managers.

W^X copy?

[Tom]

The article linked doesn't say much about this "breakthrough technology", but from what I could gather, it looks rather like a cheap (and incomplete!) knock-off of OpenBSD's W^X (write-xor-execute). Anyone know more technical details?

Better Late Than Never

[SunFan]

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.

Re:Better Late Than Never

[weicco]

What I remember is that OpenBSD's stack protection isn't few years old, at least in x86 :)

Good naming, marketing. :-)

[Tom]

A fitting name. In German, a Depp is another word for stupid idiot.

Now, a translation into non-technical terms

[dsplat]

You were at your buddy's place to watch the Super Bowl. The chips ran out in the second quarter. Since you knew there was no way the half time show was going to be as interesting this year, you volunteered to go get more.

On your way out you made a mental note to come back to your buddy's place, rather than your own. This is the return address. You also made a mental note that you needed potato chips and another case of beer. That list is in your buffer.

Your other "friend", a known sponge who still owes several people for beer at various events dating back 3 years now, comes along. While you are at the store, he throws an extra case into the cart. He'll pay you back later.

That annoyed you enough that you forgot whose house you were going back to. You ended up at your place before you realized it. As a result, you missed the first few minutes of the third quarter.

LISP

[fionbio]

So, with this great feature, I will be unable to say (compile 'my-function) in my LISP REPL, because it creates executable code in data section?

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

No problems so far.

[Software]

I haven't used a CPU that supported NX natively. My only experience with DEP is on an IBM T21 laptop with XP SP 2. I have had no problems with IE, Office 2003 (Outlook, Excel, Word, PowerPoint), Firefox, Symantec Antivirus, GAIM, Perl scripts (mostly my own), several Java apps, and several other third party applications written in Delphi, C/C++, etc.

I even enabled DEP for all programs and services, not the default "essential" ones.

DEP is Spanish for RIP

[Corunet]

In Spanish, DEP stands for "Descanse En Paz", or "Rest in Peace" in English

It's an intel flaw

[spitzak]

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

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.

Re:It's an intel flaw

[maird]

Segments exist in 32 bit x86 flat memory model environments too. Code is loaded from cs:eip and data is accessed at ds:offset (there are several modes for determining offset). A flat model makes it possible for all references to be near (no explicit segment) but that only means cs is implied (code) or ds is implied (data) es may be implied too for string instructions. The OS loads cs once and ds(,es,fs,gs) once for any user mode process but segments are still loaded and used. NB: I'm talking about what you can do (in response to you your "could not" point), not what you might prefer to do when implementing an OS (I don't like segmentation either). I don't believe it is true that you can't make memory readable and not executable but AFAIK these exploits depend on writing and executing anyway. I believe you can make addresses executable but not writable on an x86 without NX. Segmentation allows you specify a base address and limit for a descriptor that can be selected by cs (what eip must be an offset in). If you have no writable data descriptors that overlap any code descriptors then a user mode application can't execute arbitrary code by poking instructions into memory. IIRC, you'd get a GPF trying to write opcodes where you could execute them or a GPF attempting to jump to an address where you could write opcodes. You can also make code readable by putting it in read only pages but, if cs has a 4GB limit, you can't prevent a program from running arbitrary code it pokes into memory it can write to. I think that is the real cause of the problem and the OS chooses the values of the base and limit for cs. NX provides executable control in the paging system but it has been available in the segmentation system since at least the 386 (can't remember 286 descriptors). You have to use segmentation even in a flat model (implicitly) but you don't have to use paging. That (and MS bugs) may be a factor in the time it has taken to develop NX. FWIW, I don't advocate segmentation and an executable page attribute has been missing from the x86 MMU since the 386. IMO it is an omission in the x86 design that you can have supervisor and user segments in read, read/write and executable types, but supervisor and user pages in only read and read/write types.

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. :)

Early AT&T Unix

[rlp]

Early versions of Unix (circa early '80's) running on PDP-11's split application memory into Instruction and Data space. Instruction space was the programs instructions and data included static, stack, and heap space. Data space was not executable. So a buffer overrun could result in a core dump (GPF) but not a security violation. Please keep this in mind, when MS is issued a patent on their novel DEP scheme.

Re:Early AT&T Unix

[eric76]

It's amazing how many good ideas are "reinvented" years after they were shown to be viable.

For those who aren't familiar with the PDP-11, the I and D space allowed us to double the amount of memory allocated to a program. A program and all of its data had to fit in a very limited address space. By using I and D space, a program could double that.

Using I and D space, if a program wrote something to memory at location 4000 and then branched to location 4000, it would be two different locations in memory. That is, memory location 4000 in D space and memory location 4000 in I space were on two different pages of memory.

However, DEC didn't really use I and D space much. At least, the RSTS/E (Resource Sharing Time Sharing / Extended) operating system didn't, to the best of my knowledge, use I and D space. I asked one of the RSTS/E developers about this at a DECUS once, but didn't get much of an answer.

Using I and D space would have had some consequences. The PDP-11 instruction set included a MARK N instruction that couldn't be used in I and D space. The N of the MARK N instruction was a count of the number of arguments in a subroutine call.

When calling a subroutine using the MARK N instruction, you would push the MARK N instruction, with the appropriate N, onto the stack. When returning, you could branch to that location on the stack and execute the MARK N instruction which would perform your stack cleanup for you. So you were actually writing an instruction to memory and then later, branching to it.

I don't think that the MARK N instruction was used all that much. In one of the popular PDP-11 assembly language books, the section on the MARK N instruction was just flat wrong. It was obvious that the author had never actually used it.

At a Spring DECUS in New Orleons (1984 or 1985), in a discussion session on assembly language programming, tips, and tricks, someone asked about the MARK N instruction. The speaker/moderator asked how many people had ever actually used the MARK N instruction, but I was the only one I could see to raise a hand.

Re:great news

[FooBarWidget]

Does Linux have something like this? Fedora has had Exec-Shield long before Windows had DEP.

Anger. Fear. Aggression. The dark side are they.

[leuk_he]

But beware of the dark side. Anger... fear... aggression. The dark side are they. Easily they flow, quick to join you in a fight. If once you start down the dark path, forever will it dominate your destiny, consume you it will,

That is the path the anti-virus company's follow. They go for quick profit. They do not manage to completely erradicate virus ever. They do not help against phishing attacks, they do not help against spyware, you need to buy another product for that. and all those products together do your pc as much harm as the first virus that comes along.

Fear: mcafee popup's a Warning about a virus every few days, that on very very close inspections was not intercepted, but it was just just advertising it could help against. fear......

interpreters - your program is data

[oo_waratah]

The program that you write in an interpretter is not executed in the classic sense of creating actual binary. It is more a case of looking at the data portion then doing something in the execution space. Your 'program' remains in data, whether in text or some intermediate compiled form.

68k

[bsd4me]

You could also do something similar with the MC68000. I can't remember if it successors also had it.

Basically, there were two extra output pins on the address bus. One signified program or data access, and the other signified supervisory versus user. So, a clever engineer could four separate memory spaces. I am unaware of any products that used it, though.

Lisp compilers

[fionbio]

;; Why do you think that modern Common Lisp
;; implementations are pure interpreters?

CL-USER> (declaim (optimize speed
(safety 0)
(space 0)
(debug 0)))
T
CL-USER> (defun my-func (x)
(declare (fixnum x))
(the fixnum (1+ x)))
MY-FUNC
CL-USER> (compile 'my-func)
MY-FUNC
NIL
NIL
CL-USER> (disassemble 'my-func)
;; disassembly of #<Function MY-FUNC>
;; formals:

;; code start: #x2083517c:
0: 83 c0 04 addl eax,$4
3: f8 clc
4: 8b 75 fc movl esi,[ebp-4]
7: c3 ret
; No value

;; This doesn't look like something "intermediate".
;; It's executable code which is created dynamically.

Re:Umm...

[m50d]

When you're running it, yes. That's why you only use it when debugging to hunt for the overflows, not all the time.

Re:great news

[grolschie]

Does linux have any sort of thing like this?

Yep, it's called code scrutiny. Kernel maintainers actually check the code submitted to them (for buffer overflows and other flaws, etc). When vulnerabilities are found after release, rather than covered up, they are promptly fixed and patches released.

Alls I can say is...

[OhHellWithIt]

... it's about damn time. Data General had a similar scheme, called ring memory, in AOS/VS about 20 years ago. You can read about it in Tracy Kidder's Soul of a New Machine.

We use McAfree 8.0i

[toadlife]

We recently deployed McAfee 8.0i in our organization. We have been satisfied with it, but one of our accessibility apps in our disabled student labs was crippled by the buffer overflow protection. We decided to just disable the buffer overflow protection accross the enterprise via EPO.

Agree and Disagree

[billstewart]

You've hit the nail right on the head with the core issue - user space code vs. kernel code. I disagree on one thing - C _was_ designed to work well in userland, but the world it lives in has changed out from under it. It's still a great language to implement some things in, even if too many people aren't good enough at it for that to be safe any more.

On the other hand, the number of people I know who rave about productivity in Python, and the convenience I've seen writing a few things in Perl, suggest that for many tasks in user space it's really better to invest the time learning a more productive language that's also safer, and Java's probably more productive than C on large projects even if it runs slower. Of course, there are the academics who'd recommend Scheme or Haskell instead of Python, but those are probably adequately safe languages as well.

Blaming the Language, not just the Coders

[billstewart]

You certainly can blame a programming language for sloppy coding, just as you can blame it for low productivity. Yes, sloppy coders will be sloppy in whatever language they choose, and wizard programmers will be wizards in whatever languages they choose, but if a language won't let you shoot yourself in the foot, or at least won't let you shoot anyone else in the foot, then the consequence of having millions of sloppy coders out there is limited to lots of people writing applications that don't work and annoy their users, as opposed to the current environment where somebody making a mistake enables a rootkit exploit leading to the next Internet-choking worm of the week, or whatever other disaster you choose.

Are there better languages than C to write OSs in? Maybe not, but as I said, the number of people writing kernel code and device drivers is *really* limited - most code is userland code, and most exploits are userland exploits - C may be in wider user than ever in user space, but there are a couple of orders of magnitude more user-space programmers than kernel programmers. Sure, crackers can occasionally stomp on your IP stack by handing it unexpected packets, but that's rare, and it's usually a DDOS problem like the Ping of Death rather than an exploit. On the other hand, how many times have you seen security-critical bugs in web browsers, ftp servers, mail servers (sendmail is *much* less bad than it was, but I still wouldn't bet money on it being safe), other random things running from inetd, or for that matter even jpeg viewers have had security-critical buffer overflows in the last year.

That doesn't mean that enforcing safe languages will create total safety, of course :-) There are still lots of popular attacks that are language-independent, such as trying file pathnames with ../..'s in them in case the program isn't checking carefully for things like that. Operating System permissions can help prevent attacks like that from cracking root, but they don't always stop a web server from letting browsers write to the wrong place in a single user's web space.

Question

[bmac]

As a long-time C programmer, I'm curious as
to what you mean by "anonymous functions" in
C. (This is *not* a troll.) Example code is
always welcome. Other than that, thanks for
the useful post.

Peace & Blessings,
bmac

Re:Question

[pchan-]

Aha, I knew something didn't look right there. Thank you for pointing out my ignorance. What I meant was "nested", not anonymous functions. This is what the OpenBSD people were having trouble with. Anonymous functions don't exist in C, to the best of my knowledge.

This is a gcc extension that is not standard C, and is generally a stupid idea and should not be used by anyone, ever. Now that I've given the disclaimer, they go a little something like this:

#include <stdio.h>

void go(void)
{
int i;

/* this is a nested function
it is only valid in the scope of function go() */
static void nested(int x)
{
printf("%d\n", x);
return;
}

for(i = 0; i < 5; i++) nested(i);
}

int main(void)
{
go();
return 0;
}

Re:Question

[bmac]

Thanks, I thought I had missed something
there for a moment. I seem to remember
from long, long ago, my using nested
functions in some environment/lang and that
I liked them. Of course, now I shudder
at the thought :-)

Peace & Blessings,
bmac

Doesn't anybody remeber PSECTs?

[droolinggeezer]

This is just another case of how we collectively forget great truths. When I was writing compilers for PDP-11s and VAXen, they generated CODE and DATA type Program SECTtions. Those got loaded into PAGEs with appropriate protection characteristics (executable, read-only, etc). What happened that we abandoned all this while the processors remained capable of support for these characteristics is a real mystery (did we get tired or just get lazy?). Of more modern concern, what impact does I/D (instruction/data) space have on JVM implementations?

Reinventing the wheel

[multicsfan]

Putting data and code in separate segments is nothing new. making data read/write only and code read/execute only isnothing new. This was standard on Multics (http://www.multicians.org). I believe Bouroughs and other vendors also did this as a standard feature back in the 60's as well. I find all this reinvent 60's and 70's technology very amusing. Why does everyone have to keep reinventing solutions?

Intel's Fault

[pcause]

Why are we bashing Microsoft here when the fundemental issue is that Intel didn't design the architecture corrently. As has been said, we've known forever, that executable pages of memory should not be writable. It was well know before the i386 was designed. Intel deserves the lions share of the blame here.

Linux and UNIX are more secure becuase they use a file system with permissions and user accounts do not have permission to write into system directories. Most UNIX systems are administered and Linux systems are used by more techie folks. When it was just a FAT file system, there were no permissions so anyone could modify any critical file.

With NTFS, files in critical directories can be protected. The problem becomes getting people to take the step of not having user accounts have admin rights. People can already do this in XP Home, but few do. The problem is that this would be viewed as inconvenient to most home users who don't udnerstand enough to know why they need this extra step to protect them. As long as home users grant admin privileges to everyone on aa system and then blindly download and install software, this problem can not be solved.

Even then, Microsoft needs to extend the privilege model to only allow designated applications to insert code in the TCP stack, keyboard stack, etc. Their spyware stuff sort of detects many of these issues, but the OS needs to control them.

MS says they are serous about secrity and it is priority one. Allowing any kind of install of a system component without admin control is unacceptable if you want a secure system. To get security we are going to have to sacrificae some convenience and flexibility, but how do we implement this when so many users are so technically niave, unsophisticated, unwill to do the slighted extra work to keep their systems safe, etc.

As an industry we need to stop bashing MS and start educating users that security is their problem. leave your car unlocked in a high crime area with the keys in it and you should take the blame, not GM. The Internet is a high crime neighborhood and unless you take personal responsibility and avoid the dark alleys, giving your wallet to strangers and leaving your car and house unlocked, you are going to get robbed and assaulted.

Totally untrue!

[x2A]

The NX bit says that code is not to be executed on a per-page (usually 4k) basis WITHIN AN EXECUTABLE SEGMENT. You can have non-executable segments, and you have been able to for over 20 years on the x86 processor range, without the NX bit. You'd just need to make sure your code segment doesn't reach as high as your stack segment, and that would solve most of the problems. (It's also possible to create executable read-only segments, so that code can't be changed once loaded in.)

Unfortunately, doing something like that this late into OS development can be quite tricky and could break some software.

But this is definitely down to the OS guys, not the chip guys. If ya don't believe, check the 386 white papers, look for details on the global descriptor table.

-2A