Motherboards Memory Storage Cases/Cooling/PSUs IT Computing Displays Mobile Mac CPUs & Chipsets Video Digital Cameras Linux Gadgets Systems Trade Shows Guides Home Increase Font Size Decrease Font Size Change Page Size
A bit about the NX bit; Virus Protection Woes
A bit about the NX bit; Virus Protection Woes
Date: October 11th, 2004
Topic: CPU & Chipset
Manufacturer: Various
Author: Kristopher Kubicki
Buy the AMD ADO5200IAA5DO Athlon 64 5200
Blank
 TigerDirect $54.99
 CompUSA $54.99
 TigerDirect $68.18
 
 

Introduction

NX protection seems great; it stops viruses dead in their tracks and eliminates those pesky buffer overflows we have been hearing so much about for the last 15 years. Well, maybe not. In fact it seems that NX provides several layers of false security, particularly since it only stops some buffer overflows and whether or not it stops any viruses has yet to be seen yet.

Although AMD and Intel both like to spin their newest NX/XD "Virus Protection" as a new feature on x86 technology, in reality NX behaves more like an emergency patch for an easily exploitable architecture. To really explore how NX benefits us, and where it provides a false sense of security, we must understand one of the scenarios that it supposedly prevents against.

The simplest explanation of a buffer overflow is when a program executes memory it was not intending to. Typically, this is done when a program writes something into memory that it has not properly allocated for; sometimes writing over pieces of the same program already in memory.

For example, let's take a look at the following program code:

int main(int argc, char **argv)
{
           char line[512];
           line[0] = 0;
           gets(line); 
           ...
           return 0;
}

Undoubtedly, even those who have taken only rudimentary programming classes are having a good chuckle with the monstrosity above. However, this code is actually nearly verbatim copied from the original UNIX fingerd program circa 1988. In UNIX (or any other operating system), the entire contents of the program are loaded into memory as machine code. A simple, although not necessarily proper, way to think about the above code is an array of several hundred bytes in memory; 512 bytes allocated for the array of characters, line, on line 3 of the code.

As the program starts flipping through the code in its array (which is actually called a stack), it reaches the function gets(). gets(), a horrible, ancient function, reads input and places it into the line array. But line has only enough memory allocated for 512 characters! It would only take a malicious user a few seconds to realize that writing more than 512 characters to the fingerd program would result in the ability to write data past the end of the line array. And since line exists inside a stack in memory, writing past the end of line actually starts to overwrite critical pieces of the program! If a user were to write 512 characters to fingerd followed by machine code, the user could essentially control any attribute of the entire machine. The example with fingerd above became the first real internet worm exploit, a buffer overflow. Worms like Nimda and Code Red work exactly the same as the original fingerd worm, so unfortunately 16 years later imprudent programming and exploitable hardware are still to blame.

What does it all mean?   Next Page

 
  Index

Tools Share
Find lowest prices Find the lowest prices
Digg   del.icio.us   E-mail  
Print This Article Print this article  

17 Comments - Last by Andyvan, 1907 days ago
Username:
Password:
No Subject by TrogdorJW, 1946 days ago
Of course, this is to say nothing of the difficulty of stopping dumb people from launching any number of Trojan horse type applications. "Hey, pictures of [insert celebrity name]! I gotta see this!" We need an NM bit: No Morons. ;)

Reply
No Subject by Pythias, 1945 days ago
No kidding! Our surfing/email habits have as much to do with our security as any piece of software in the world.

Reply
No Subject by reever, 1943 days ago
Typo: All memory is divided up into several SEGEMENTS;

Reply
No Subject by KristopherKubicki, 1943 days ago
Fixed.

Kristopher

Reply
No Subject by Foxbat121, 1943 days ago
NX bit is nothing new. It existed in Intel 80286 processor and no body liked it back then. So Intel took it out.

On the other hand, the NX protection is XP SP2 is only limited to stack memory only. In WinXP 64bit extention for x86-64, Microsoft extends protection to all memory segments that is marked for NX, not only stack memory.

Reply
No Subject by WarcraftIII, 1942 days ago
"Well, maybe not. In fact it seems that NX provides several layers of false security, particularly since it only stops some buffer overflows and whether or not it stops any viruses has yet to be seen yet."
Why start off by questioning whether NX will even be able to stop any exploits? You only have to look back at what viruses rely on executable stack memory to see how useful this can be, not wait around to see if anyone ever comes up with one.
Of course it doesn't stop all buffer overflow exploits. It could be as simple as entering machine code into an input that will be placed on the heap. At a later point in the program a stack-based buffer overflow could overwrite a return address or a function pointer variable with the appropriate address. You could conceivably avoid the stack altogether where a buffer on the heap overflows onto a function pointer variable stored on the heap. It doesn't change the fact that this can stop a lot of exploits, and probably the simplest and most successful exploits because positioning of items on the stack is a lot more predictable and you are a lot more likely to guess a close enough to correct return address (you can guess an offset from other addresses obtained off the stack).

Why does this article try to present buffer overflow exploits as being due to inherent problems with x86? The usual calling conventions on pretty much any architecture involve storing return addresses on the stack which makes exactly the type of exploit the NX bit stops a possibility. Where one is provided, the contents of the return address register need to be saved to memory if you're doing calls more than one level deep.

"in reality NX behaves more like an emergency patch for an easily exploitable architecture"
Is x86 really any more exploitable than anything else? The memory model you described is not x86-specific.
Why do so many other architectures support an NX bit?

"both started working with Microsoft to patch the x86 architecture itself. The inherent flaw is two fold; for one, malicious code should not write past the end of an array like line from fingerd, and second the computer should not continue to happily execute the machine code on the stack."
The computer is doing exactly what it has been asked, and it will do exactly the same thing whether you're using an x86 or not. This code SHOULD write past the end of the array if the user enters a lot of characters because that is what the programmer has written. This is due to the design of C, not x86. If this is not supposed to happen (as it obviously isn't in the example) it is solely due to programmer error, it is not the fault of x86. If you want bounds checking use Java, if you want speed write decent C/C++ code whether you're using x86 or not.

I'm sorry if I sound overly critical and I guess I may be wrong in some of my assertions since I haven't done much assembly programming for a fair while. However, it seems to me that the point of the whole article was to criticise the NX bit as a relatively useless hack (or "emergency patch") useful more for marketing than for security purposes, and I believe this to be incorrect.

Reply
No Subject by bobbozzo, 1942 days ago
Do the 32-bit versions Windows Server 2003 support this on AMD Opterons?

Thanks!


Reply
No Subject by KristopherKubicki, 1942 days ago
WarcraftIII: Although I agree with your comments on programming error, let's look at the last 20 years of programming as an example. If we have the ability to stop Buffer Overflows do we rely on 4 processor makers or 200,000+ C programmers to fix the problem; either of which can fix the errors with equal amounts of work?

NX is OK, I am just illustrating it doesn't do what it says. It might have stopped some older worms, but when the next worm hits that moves around the eip to somewhere it shouldn't and "buffer overflows" all those NX protection machines don't you think people are going to be upset?

Most RISC and MIPS processors have utilized some form of NX protection since their inception, by the way.

Finally, I would like to add that OpenBSD's w^x protection (writeable xor execute; no execute on any writable segment) is probably the most elegent solution yet to the buffer overflow issue. It still is vulnerable to maliciously modified return pointers, but it doesnt advertise that it isn't.

Kristopher



Reply
No Subject by Pax Team, 1941 days ago
OpenBSD's W^X is only a subset of what PaX has implemented for 4 years now, but thanks for the praise anyway ;-). As for ExecShield, it doesn't implement W^X, data and bss sections in libraries remain both writable and executable. And both OpenBSD and ExecShield are vulnerable to executing existing code that can trivially circumvent W^X separation and execute injected shellcode.

Also, you're mixing up software bugs (that your 200,000+ programmers can fix) with exploit techniques (some of which properly used hardware features can prevent). The two sets are orthogonal, not mutually exclusive.

As for MIPS, as far as i know, none of them has true hardware NX bit support, although on some models it might be possible to simulate the behaviour, but it's lots of hacking and is mostly an academic exercise only, not useful for production.

Reply
No Subject by KristopherKubicki, 1937 days ago
Pax Team:

Correct about W^X and Execsheild; same for NX as well too.

"Prescott supports the NX - for 'no execute' -- feature that blocks worms and viruses from executing code after creating a buffer overflow on the machine", said Paul Otellini, Intel's COO.

The scope of the article was to show that NX doesnt do what Intel's COO even believes it does.

I am a little confused about your second paragraph though, can you please elaborate? Thanks for the feedback. Please email me when you get a chance.

Kristopher


Reply
Comments Page 1 of 2

Unlicensed Software at Your Last Company
Anonymously Report Unlicensed Software with Our Form Now. Get Up to $1 Million.
We Buy Laptop and PC Memory! Sell to Us!
Min of 25 pieces required. Call us today at 239.354.1230.
Special Offer from The Economist
Get 12 issues of The Economist for $12. US subscribers only.
Free Forrester Risk Management Report
Demystifying Enterprise Risk Management. Download Free With Registration.
Download Microsoft Visual Studio ® Team System
Streamline Dev processes, Reduce time to market. Try Microsoft Visual Studio Team System, FREE!




Latest news by
DailyTech

 February 9, 2010

Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank
Blank

 February 8, 2010

Blank


more CPU & Chipset Discussions



pipeboost
Copyright © 1997-2010 AnandTech, Inc. All rights reserved. Terms, Conditions and Privacy Information.
Click Here for Advertising Information