Red Hat Introduces NX Software Support For Linux 188
abertoll writes "In this story at ZDnet, Red Hat has apparently added NX support to Linux. NX security technology is a hardware attempt at stopping malicious code." (We recently posted about Transmeta's announcement that its chips will incorporate the NX bit as well.)
Difference between NX and protected mode bits? (Score:3, Interesting)
Per-segment vs. per-page (Score:5, Informative)
Standard 386 protected mode controls per segment, where CS (code segment) is executable and DS (data segment) is writable. However, many 32-bit operating systems use a so-called "tiny" memory model, setting CS = DS, and the 386 allows for turning off read and write privileges per page but not execute privileges (if you can read a page in an executable segment, you can execute from it).
However, true W^X (shorthand for "no segment is both writable and executable") support won't work for applications that depend on self-modifying code, such as JIT-compiling virtual machines for Java and .NET platforms.
Re:Per-segment vs. per-page (Score:5, Interesting)
data char* temp = new data char[len];
executable char* code = new executable char[len];
int function() = code;
compile(javasrc, temp);
copy(temp, code);
function();
From what I've heard, allocations will default to non-executable, but there will be some sort of API that allows executable space to be allocated on every OS that deals with NX bits. You will probably also see WinXP and the like with the ability to "Run this program in compatibility mode..." until the developer updates to deal with the tweaks made in the updates.
Re:Per-segment vs. per-page (Score:3, Interesting)
compile(javasrc, temp);
copy(temp, code);
function();
And watch as NX::copy() has a huge overhead from going into kernel space and back.
Re:Per-segment vs. per-page (Score:2)
From what I've heard, allocations will default to non-executable, but there will be some sort of API that allows executable space to be allocated on every OS that deals with NX bits.
Fortunatly, Unix already has an API for that, both mmap and mprotect have the PROT_EXEC flag. There may be a few apps that get into trouble for not using it where it's needed since on x86, it's effectively been always set up until now.
Re:Per-segment vs. per-page (Score:3, Informative)
Re:Per-segment vs. per-page (Score:2)
I have heard this is a serious problem for LISP as well. I hope, for the sake of these platforms, that W^X, which seems to be the future for most operating systems will have some sort of loophole for the neat and useful computer language features that aren't compatabile with it.
Re:Difference between NX and protected mode bits? (Score:1, Informative)
Re:Difference between NX and protected mode bits? (Score:5, Informative)
Re:Difference between NX and protected mode bits? (Score:5, Informative)
Linux, Windows, BSD, etc. don't use segments, but instead use paging. Intel has dragged their feet on adding NX support because the feature "already exists", but the reality is that hardly anyone uses segments.
Ok, technically everyone uses segments -- they just create a single segment which covers all of the memory space. The GDT (Global Descriptor Table) must be configured when you switch to protected mode. Paging is optional.
The NX flag prevents a page (typically 4k) from executing. By marking all stack pages as NX, buffer overflow attacks won't be able to remotely execute arbitrary code. I assume that an exception will be generated when an attempt is made to execute from an NX page, which will probably cause the running program to halt. So, remote explots turn into DOS attacks.
Buffer overflow attacks have been known about for decades, and solutions such as NX have been known for quite some time too. As has been mentioned elsewhere on /., this does not remove the responsibility of developers to write good, secure code. But, as history has shown, they will probably continue with the long standing practice of writing insecure code.
NX will prevent buffer overflow attacks. NX will not be able to determine whether a program you choose to execute is good or evil. Viruses existed and managed to propogate back in the days before the Internet or even networking were in common use. NX won't solve all security problems, but it is a good tool to help reduce the possibility of remote exploits.
The NX flag isn't new, it's just new to the x86 world. Kudos to AMD for being the first to add this to the x86!
Re:Difference between NX and protected mode bits? (Score:3, Informative)
the NX bit operates at page level - within segments. it is bit 63 of the Page-Translation-Table entry, and is only available in PAE mode. it is enabled by the NXE bit of the EFER ("Extended Feature Enable Register"). and it applies to all execution rings.
Re:Difference between NX and protected mode bits? (Score:2, Interesting)
This is why linux is so efficient; bugs are corrected in the kernel and recompiled for the new releases. It's a much better solution that adding code bloat or processor o
Re:Difference between NX and protected mode bits? (Score:3, Informative)
All modern architectures implement all 3 different protections bits (read, write, execute). It should have been implemented a long, long time ago, and you definitely cannot emulate it perfectly in software.
I don't known why it wasn't implemented from the begining or at least when the 386 was released, but it was sorely missed by everyone working on improving the security of an OS. I guess Intel didn't think that this architecture would survive in the 21th century.
So adding the NX is a long
Re:Difference between NX and protected mode bits? (Score:3, Informative)
Point taken, but if NX cuts down on the worm/virus/virus notice email we get because of infected Windoze systems, it'll be a performance boost for us UNIX users.
Re:Difference between NX and protected mode bits? (Score:5, Interesting)
Linus sloppily decided to avoid _almost all_ of the protection mechanisms that the 386 makes available to the system. That's why you can smash the stack for fun and profit. He chose to let CS access the same pages as DS (and SS,ES,FS,GS), whe he could have allocated some linear addresses as code-only, and others as data-only. After that you simply need to ensure that no CS ever was given access outside the executable range, and no other segment was given access in the executabe range.
And you can ensure this - as you, the kernel, are entirely in charge of setting up user-space descriptors.
To do so would have added a bit more complexity to the memory management (with lower case letters) part of the kernel, but would have prevented all smash stacking and heap smashing attacks.
Linux is not _technically_ as good OS at all. It's simply _practically_ (for people like me) a good OS.
Tannenbaum is still right. (And when Tannenbaum says "run 20% slower" he means "take up 0.6% of the CPU rather than 0.5% of it, thus giving apps 99.4% of the cpu rather than 99.5%. But that's another rant.)
FP.
Re:Difference between NX and protected mode bits? (Score:2)
Well, this is pretty low-level hardware operation-type stuff we are talking about. If you call this feature a "patch" that shouldn't exist, then you could say the same thing about processors knowing how to do almost anything at all... Those lazy developers don't really NEED a subtraction function on the processor. Those software guys don't NEED a BIOS to interface with the hardware. Those software guys
Re:Difference between NX and protected mode bits? (Score:2, Informative)
There's absolutely no thing as the execute bit in 386
There is, but it works on segments and not pages. Unfortunately, some i386 operating systems' ABIs are defined such that CS = DS.
The 386 architecture has one bit for access:
Your one-bit write protection applies to pages.
NX Virus....yay (Score:3, Funny)
The NX Bit... (Score:5, Funny)
Re:The NX Bit... (Score:1)
Silly person, the evil bit is part of the network packet and should be handled in the routing fabric instead.
Re:The NX Bit... (Score:1, Funny)
Read the Jargon File lately?
Remember kids... (Score:2, Insightful)
Re:Remember kids... (Score:3, Insightful)
However, bugs happen when writing code.
Worse bugs happen when someone modifies code they don't understand. Some code depends on non-explicit assertions, such as an array size being already checked somewhere else, or some buffer being already initialized somewhere else. The maintenance programmer sees the code like through one of those cardboard tubes in toilet paper rolls, so he/she can easily miss such dependencies. When
Darn. (Score:1, Offtopic)
So does this mean I'm out of luck with all those shellcodes I keep posting in my comments?
Re:Darn. (Score:1, Interesting)
no execute support new? Nonsense ! (Score:5, Funny)
Why just yesterday it stoped executing for no particular reason.
Re:no execute support new? Nonsense ! (Score:1)
Re:no execute support new? Nonsense ! (Score:1)
Hmm, last time I used MSWindows, it said "General protection fault" and now it just says "no particular reason".
Congrats Bill, you truly are an industry something-or-other.
Re:no execute support new? Nonsense ! (Score:2)
Re:no execute support new? Nonsense ! (Score:2, Informative)
From what I've read, NX support on older i386 CPUs either 1) puts all of a process's code below the code segment limit (1 GB) and all data above that, with an unmapped gap in between [neohapsis.com], or 2) hooks into the translation lookaside buffer (the cache for virtual memory page table lookups) at a speed cost.
Re:no execute support new? Nonsense ! (Score:2)
Re:no execute support new? Nonsense ! (Score:5, Informative)
Re:no execute support new? Nonsense ! (Score:2)
mczak
Re:no execute support new? Nonsense ! (Score:2, Informative)
There you go (Score:4, Insightful)
See, NX is a good thing, now even Linux has support for it
Cheers.
One step at a time (Score:1, Interesting)
Re:One step at a time (Score:2)
Re:One step at a time (Score:2)
It stops you from accidentally executing your data (e.g. buffer overflow onto stack).
Open BSD has it. It's a security enhancement. Even if you're running windows, you don't want buffer overflows. It's good. It's not DRM.
Re:One step at a time (Score:2)
It has little or nothing to do with "Trusted Computing". The OS is free to set or clear the NX bit as it sees fit, including at the command of the user. "Trusted computing" is more like having a ring -1 and the OS being powerless to do anything about it.
Re:There you go (Score:1, Offtopic)
Re:There you go (Score:2)
Yea, right, open my mind. Haven't you ever heard of cognative dissonance? It means I can hold two contradictory thoughts in my head and not be bothered. So Microsoft is evil for including NX, and linux is awesome for including NX. What do you have to say to that?
Just don't add "Halt and Catch Fire" Instruction (Score:5, Funny)
Seriousely, the NX stuff is a "good" thing to add to slow down malicious code - the only thing better would be a HULK Instruction [komar.org] which would SMASH Puny Human malicious code ... ;-)
A cross between... (Score:5, Insightful)
Fine No Execute (Score:5, Insightful)
No execute means that somewhere, somehow there will be an override and the day the override is used the virus' will follow by tricking (and explaining how) to the user why this is needed and bingo, it's in.
And of course I could be completely wrong in that this no execute bit does not exist on older processors and that in itself is going to cause problems. Intel has xbit on newer processors, but what about AMD, VIA, whoever else? Is this part of the Intel half of the WinTel duopoly?
I think it's probably a good idea, but I'm suspicious.
Re:Fine No Execute (Score:2)
Re:Fine No Execute (Score:5, Interesting)
In other words, Intel is playing catch-up.
And note the comment in Ingo's linux-kernel posting that refers to the "existing NX support in the 64-bit x86_64 kernels
Comment removed (Score:5, Informative)
Re:Fine No Execute (Score:2)
Why don't people use different stacks for return addresses and parameters/variables?
That way one reduces the chances of "running arbitrary code of the attacker's choice". In event of a bug the attacker is more likely to only easily "overwrite/specify arbitrary paremeters/variables for existing functions". Which seems magnitudes safer.
Re:Fine No Execute (Score:2)
It's not really a bad idea, but I'm not at all sure how easy it would be to implement with the current compilers & code-base. I suspect quite difficult. The NX bit is probably transparent on systems that don't have the capability, which a dual stack system wouldn't be. (OTOH, a dual-stack system wouldn't need to depend on new CPUs.)
Re:Fine No Execute (Score:2)
You mean like FORTH?
Exactly like FORTH! The fact that FORTH runs on nearly anything shows that hardware support isn't required, but having explicit support for a data stack might be interesting for performance.
Although it would be a bit of work, with a modified kernel syscall and gcc, it could be implemented on existing hardware.
Re:Fine No Execute (Score:2)
As for FORTH - I heard it's still vulnerable to buffer overflows.
Plus if you're not careful the fact that typically code=data in FORTH just creates the same problem in the next level. Joe Programmer may not know to use different "dictionaries" or whatever they call those, to isolate things.
A while back I crashed a forth webserver on my first try (zhttp). Sent a single quote to a http basic-auth password prompt... It really crashed too. Do
Re:Fine No Execute (Score:2)
Re:Fine No Execute (Score:2)
As for the other stuff, I think just a single general parameter stack may be good enough - let the programmers figure out what they want to pass to routines and how they want to do it.
Shouldn't be too difficult to detect if the stacks collide. Start and current pointers for each of the two stacks, or something similar. Load in the pointers for each context switch.
Th
Re:Fine No Execute (Score:2)
Re:Fine No Execute (Score:5, Informative)
As far as it not being on older processors, I assume you mean older ia32's, and surprisingly this was brought up in a MS TechNet event I was at on Thursday. I don't know all the details, but he presenter said it was in older chips, at least back to the original Pentium if I remember, but with the way ia32 chips do paging, it was never implemented in the OS's until recently, which i can only assume the Athalon64, Opeteron and Itanium do this differently, but don't quote me on that.
Personally, I'm just wondering exactly what ia32 chips will Linux and OpenBSD use NX on.
Re:Fine No Execute (Score:4, Informative)
New ones. People will buy them because they want "Enhanced Virus Protection".
In the case of older chips: well, that is what exec-shield is for.
Re:Fine No Execute (Score:4, Informative)
First of all you shouldn't expect the NX bit to do any good against a virus. A worm OTOH might be stoped by the NX bit. OK I'll assume you mean the worm would use a way to override it. If it could be disabled per executable like execshield on Linux, you could only exploit vulnurable programs with the security feature disabled. So if the vulnurable service is running with the security feature enabled, you cannot disable it, unless you already control the machine. So it doesn't help a worm gaining control.
What are the chances the vulnurable service would run with this security feature disabled? Not large, because you would only disable it, if the service didn't work otherwise. And the number of programs breaking in case of Linux is not large. Fedora Core 1 has exec shield which does a best effort at implementing this without specific hardware support. Arjan van de Ven explains [google.com] that hardly any program broke. Ingo Molnar explains [google.com] in a bit more detail, that the X module loader was the only program breaking. (Some other programs broke for other reasons). So when it is only one program breaking, you fix it, rather than starging to disable this security feature.
However as Linus has explained, there are ways to exploit a vulnurable service in spite of NX. This specific attack relies on using
JIT Compilation/Interpreters (Score:2, Interesting)
Re:JIT Compilation/Interpreters (Score:2)
Here you go... (Score:3, Informative)
Re:Here you go... (Score:5, Informative)
Of course, if those programs were written correctly in the first place they wouldn't need to be fixed to work on NX platforms.
Win32 has always had PAGE_EXECUTE flag [microsoft.com], and if you wanted to execute dynamically generated code you were supposed to include this flag when allocating memory [microsoft.com] (or use VirtualProtect afterwards).
Most people didn't bother with PAGE_EXECUTE because it wasn't enforced on x86. But technically it's always been required.
Re:JIT Compilation/Interpreters (Score:1, Informative)
Re:JIT Compilation/Interpreters (Score:1)
Re:JIT Compilation/Interpreters (Score:2)
On the other hand, if a person doesn't know the risks
calling it a "technology"... (Score:4, Informative)
Mod Parent Up (Score:2, Insightful)
Looks like only the wise understand the distinction among "tool" and "feature" and and "technique" and "technology", but the rest of the people who gather their world knowledge from buzzword driven press articles will keep thinking that Visual Basic is a "technology" as well as Java.
Actually it would be interesting to discuss how the scopes of these 3-4 concepts should be in the area
Re:calling it a "technology"... (Score:2)
Re:calling it a "technology"... (Score:2)
Space the Final Frontier... (Score:2, Funny)
I'm Captain Jonathon Archer of the starship, Red Hat Enterprise, NX-01 class security. ;-)
AMD once again taking the lead. (Score:5, Interesting)
This year has truly been AMD's year to guide the microprocessor market. Remember not so far back when everything AMD did was a response to Intel? This year it's been Intel responding to AMD. I hope this trend continues as it shows that the so-called WIntel stranglehold is starting to crack and that it is possible for the competition to assume a leading role in the market. Now hopefully, IBM has something in the works for it's PPC/Power lines, as they've been working closely with AMD and this processor feature is something that every networked system could use.
Re:AMD once again taking the lead. (Score:3, Insightful)
Re:AMD once again taking the lead. (Score:2)
Including the stupid stuff, like switching to "slot" processor/mobo interfaces...
Well, on the plus side, AMD learned very well from their mistakes... After that, they've stuck with "Socket A" this whole time, while Intel conituned the madness, switching to a different socket every month it seems.
Then again, AMD64 seems to have put them back in the mad mindset again, having 3 different sockets for their parallel chip lines. Hope th
Re:AMD once again taking the lead. (Score:2)
Not at all... AMD could easily have stayed with the Socket method, rather than switching to a Slot processor interface.
Compatibility between different Slot interfaces is completely irrelivant.
Kernel 2.6.6 included a x86_64 NX patch (Score:5, Informative)
The 2.6.6 kernel already included an NX patch for x86_64. Details are in the "Non-Exec stack patches" LKML thread here [seclists.org].
NX, Impressive! The processor has learned well! (Score:5, Insightful)
translation:
Malicious code executing itself via a buffer overflow is actually one of the lesser evils in the virus world. Most users will gladly allow anything to run on their box, especially if it does something cool (time, weather, cutesy things, etc), and with everyone being root on Windows boxes, this means the program can do whatever the hell it wants and windows won't say anything/much.
The NX bit is great, especially for servers where generally the only kind of attack is a buffer overflow. Like I said the procesor has learned well, but the users must learn also.
definitely helpful but no silver bullet (Score:3, Informative)
Think of this as raising the bar. Of course, the "clever" attackers will still find flaws, and still write code for the script kiddies to use to exploit them.
Intel wrote Linux wireless support? (Score:1, Offtopic)
http://zdnet.com.com/2100-1104-5227102.html [com.com]:
Don't they mean that Linux had new wireless network support this year? Or was Intel the wireless support contributor for Linux? Either way I think the sentence is in error. Though I'm probably just being pendantic for raising it.
---
VPS Hosting [rimuhosting.com]
Re:Intel wrote Linux wireless support? (Score:2)
From the same creators... (Score:2)
Exciting news... (Score:4, Informative)
From what I've read, it certainly makes sense to break a few apps for this functionality, as you can always run them in a build without it. Things should be a lot safer, as crap like buffer overruns from carefully formatted input strings can no longer contain executable code.
I think this should be available for individual programs to set the NX bit on memory pages that should only contain data, so, for example, when you download a file, it is impossible to execute it (say, while in memory) until you save it and explicitely set the execute bit. In other words, there is a completely non-executable path for all untrusted code from its inception until the user explicitly makes it run. Now, when some Joe Luser clicks an email attachment virus made for Linux, if this ever happens, it will be very difficult for him to make it run, and hence, it won't. Add to that the protections inherent in all Linux systems (multiuser permissions, heterogeneous configurations, etc.), and it's very unlikely that Linux users will experience the kind of crap that Windows users have to put up with on a daily basis, even if Linux somehow gains a huge market share on the desktop.
These are exciting times.
You are confused about what this does (Score:2)
The NX bit is used to mark parts of memory of a running program. Certainly it will mark anything allocated from the heap, such as the memory used to store a piece of data downloaded from the net, and then written to the disk. However it does not have any magic "sticky" property that stays with the data. If the downloading program thinks that data is a program that should be run, rest assurred that it will have the capability of saving it
NX and Self Modifying code (Score:1)
Although, I don't know if SM code is supported on Linux - Under Windows you had to use 'VirtualProtect with PAGE_READWRITE -, anyway it's a bit 'outdated' technique - lot of cache misses issues, Intel was against SM code, although i used it a lot a long time ago). So it shouldn't be a real issue.
The question is : can NX will disable with the (root) user under Linux, as it will be under WinXP SP2 ?
Re:NX and Self Modifying code (Score:4, Informative)
There's some history of self-modifying code from the 16-bit DOS world, but it's probably time to kill that off.
It's been a long time since self-modifying code improved performance. Today, self-modifying code on an x86 machine works something like this.
So, in general, self-modifying code is not going to help performance. Generating blocks of code and then making them executable is fine, but changing code you're about to execute went out with "ALTER paragraph-name TO PROCEED THROUGH paragraph-name" in COBOL.
Re:NX and Self Modifying code (Score:2)
Re:NX and Self Modifying code (Score:4, Informative)
Re:NX and Self Modifying code (Score:2)
Yes Windows supports this with a call to indicate that NX should be turned off on allocated pages. They added this because they wanted Windows to work on non-Intel processors at one time. Linux has a similar ability or it would be impossible to make exec work on such processors. The problem is that apparently programs don't bother calling this when they want memory for code because it is not necessary on Intel.
For compatabilty with such programs it will probably be necessary to hav
This is very important (Score:2, Insightful)
I saw mention in the linked article that Microsoft plans NX support in th
Re:This is very important (Score:2)
PaX (Score:3, Insightful)
It comes with a pretty high performance overhead, though. A page fault will occur for any miss of the TLB cache while normally they are just loaded from the page table in main memory.
What about C++ vtables? (Score:1)
Re:What about C++ vtables? (Score:2, Interesting)
Can someone explain... (Score:3, Interesting)
Even on the 286 (running in protected mode), code segments are executable, but cannot be writeable, and non-code segments can be writeable, but not executable. I think that's basically what you want - non-executable data, and non-modifiable code (of course, the code needs to be written to memory once, but you can make it non-writeable before starting execution).
So how come we also need an NX bit on pages (knowing that pages can only be accessed if there is a segment that references them)? Do our operating simply ignore the security that the segment permissions provide, and if yes, why? Why is per-page control so much better than per-segment control?
Re:Can someone explain... (Score:3, Interesting)
Well, yes, that's what they would use if the x86 let them. As it is, a segment is either code (and thus executable, but not writeable), or data (not executable). This means that they must use different descriptors, and hence different selectors for each. From there, it seems a small step to have the segments not overlap, thereby disabling applications from writing to th
Re:Can someone explain... (Score:2)
This is just a marketing gimmick (Score:2, Interesting)
Grsecurity/pax has had a few hundred more security enhanchement improvements over the stuff the articles now here are talking about. So what's the fuzz? Hah.
Btw, the development of Grsecurity (which is the best [most secure, most effective, easiest] way to make Linux platform secure) stopped already and the project will officially die tomorrow due the lack of sponsors.
How about the DRM bit? (Score:2)
Just so know when to stop buying hardware and horde older equipment that isnt crippled.....
The NX bit is good, but a better design exists: (Score:2)
Instead of having R/W or user/supervisor bits, the page descriptor could have separate ring information for each type of access( write/read/execute), as well the ring level of the page.
Re:diff? (Score:4, Insightful)
Re:A Problem or Not? (Score:3, Informative)
Re:Will performance decrease? (Score:2)