Slashdot Mirror
Exec Shield for the Linux Kernel
DarkOx writes "There is a new patch from Ingo Molnar which can prevent overflow attacks. The scoop from KernelTrap is as follows: Ingo Molnar has announced a new kernel-based security feature for Linux/x86 called 'Exec Shield'. He describes the patch, which is against the 2.4.20-rc1 kernel, as: 'The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary.'"
Well, yes and no. Think about the analogy of this to driving. Cars today have a number of safety features, including seat belts, air-bags, anti-lock breaks, etc. Do we drive less safely because of them? More importantly, should we not include these devices in cars to increase driving safety?
I believe it was Chris Rock joking about this in one of his sketches. He claimed that airbags are NOT going to make someone drive safely. He said something like "What you need is a giant spike coming out of the steering wheel. That'll make someone drive safe!".
make world, not war
I'm trying to understand this fully, but I don't have all the background to do so.
:-)
From the announcement:
It is commonly known that x86 pagetables do not support the so-called executable bit in the pagetable entries - PROT_EXEC and PROT_READ are merged into a single 'read or execute' flag. This means that even if an application marks a certain memory area non-executable (by not providing the PROT_EXEC flag upon mapping it) under x86, that area is still executable, if the area is PROT_READ.
Is this limitation in the x86 processor MMU, or in the Linux kernel?
Is anyone working to fix this limitation? (E.g. AMD fixing it in 64-bit mode on the Opteron, or someone reworking the Linux kernel)
Furthermore, the x86 ELF ABI marks the process stack executable, which requires that the stack is marked executable even on CPUs that support an executable bit in the pagetables.
Does this statement imply that some x86 processors do the right thing with PROT_EXEC?
If Linus is willing to create a new ELF standard, could this problem be fixed? Would it be worth the pain of a new incompatible ELF standard? Are there any other problems that can only be fixed with a new version of ELF, so we can fix them together?
It would be sort of cool to get a new ELF standard, so that Linus can call the new kernel "3.0"!
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
The page says they are mapping all the code in the lower 16 MB of the address space. And they keep the first MB unmapped for NULL pointer protection.
;) They are emulating Windoze, you can't be serious about those 15 MB! That'll hardly contain GDI.DLL!
That leaves us with only 15 MB of space for code!
Are they really trying to say that they have not hit that limit yet? No program on earth has more than 15 MB code?! I can hardly believe that.
I was going to cite Emacs on this one, but Emacs is an interpreter, so the actual interpreter code might be small enough. Mhh. What about Mozilla?
Heck, what about WINE?!
Sure, this will nullify most remotely exploitable vulnerabilities, but what about local ones that are vulnerable in the manners I just described?
you're employing a somewhat dangerous hack here.
Dynamically writing code is not a dangerous hack. The more correct way of solving this problem is for people not to use unchecked arrays that can overflow - C, C++ and a few other really low level languages about the only languages that have unchecked arrays as a standard data type. Most of these problems don't show up in programs written in other languages.
Fear not my friend :-) . Please read the announcement from Ingo:
You will just need to flag your binaries ...
Hope that helps!
Well, as long as MS keeps claiming IE, IIS etc. are part of the operating system and can not be separated, exploits against those parts should be filed against the OS. In Linux, when an application gets exploited, well you don't have to run that application, you don't even have to install it, it *is* separable from the OS! Especially as there are alternatives to (almost) everything...
Regards, Ulli
Simple things should be simple, complex things should be possible.
You're forgetting XBill.
XBill is actually very pro-M$.
Because no matter what you do, sooner or later you end up with winbows on every machine on the screen.
It should be changed so that you can actually win the game. No more Bills to swat at level 10, or at 1000 points, or whatever.
-- Henriette's herbal -
Umm... do you have some vague notion of what the kernel is? First of all, it isn't spelled with an "a". Secondly, ease of use of a kernel is a very messed up concept and I'm not even sure what it means. The kernel isn't easy or hard to use any more than winsock.dll is easy or hard to use. Very few programmers interact with the kernel except through libraries, so "easy of use" (whatever you mean by that) is much more important in the low-level libraris than the kernel. How does this affect marketability to individuals? Both POSIX and Win32 APIs are available on both systems. Are you referring to clean kernel interfaces, clean kernel implementation, availablility of the source for better understanding, or some other metric?
Kernel: That word... you keep using it. I do not think it means what you think it means.
I think you're thinking about UI. The GUI, the shell, the command line, the layout of the directories, etc. are all very very far removed from the kernel. In theory you could run explorer (the Win32 shell, not IE) on top of WINE, along with all of the Win32 programs and the user would have identical ease of use as Windows. 99.99% of users couldn't tell it wasn't the NT kernel and couldn't show evidence of it being Linux even if told (without watching the boot sequence). Asking about "ease of use" of a kernel is like asking about the top speed of your house. Neither question makes much sense unless you further define your strange thinking. You could guess that the person is asking how fast a house would be going when it hit the ground if dropped from 60,000 feet up (terminal velociy) just like you could assume a person is talking about how clean a kernel's APIs are. However, the usual sense of ease of use as realated to marketing to individuals is ease of use of the UI. I can only make educated guesses as to what strange thoughts are going through your head. For all I know, you filled hard drive platters up with both kernels and are attempting to use the platters to cut 440 stainless bar stock and are referring to the different metal cutting characteristics of kernel-filled HD platters. Please clarify exactly how you think the ease of use of the NT and Linux kerenls differ.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
Except in the US where they are designed to work without seatbelts. Well, kind of. The propulsion used is much stronger in an attempt to help those that don't wear their seatbelts (one of those "we can't force them to wear their seatbelts: they're Americans, they're free, but let's tack on some copyright changes" things).
The problem is, then, that air bags in the US actually become more dangerous when seatbelts are used, but there is no evidence to suggest that they help those that don't wear them any more...
mprotect() but it cannot work properly on x86 hardware due limitations on x86 processors.
My 'day job' is programming on a mainframe. This is how they go about handling this.
:-). A code segment does not have to be read-only, but normally is. The only other 'trampolining' permitted is by using the EXecute instruction which allows you to execute one instruction in any segment. Executing (for example) a Jump instruction would be of little use to a cracker because the target address would automatically be in the segment referenced by B0.
16 'segments' (call them what you will) can be based (pointed to) at any one time, each by one base-register.
B0 points to code
B1 points to the stack
B2-B15 point to data segments.
If you want to point B0 to another executable segment, you have to execute CALL, GOTO or RTN (return
Yes, we can have buffer-overflows, but 'all' that happens is that other data is overwritten. This will usually cause the program to abort. It is even possible to organise things so that every routine has it's own discrete data-segments. If a routine then starts accessing data outside of the routine, it gets the equivalent of a Segfault. Obviously parameters/arguments are excepted from this, although there would also be a Segfault if a routine went outside it's caller's data-area.
Actually, the hardware allows a caller to restrict a subroutine's access to only the n bytes it actually passed over as an argument. The HLL implementations do not enforce this setting in any of the languages I use.
Segment attributes are from Owner-Read, Owner-Write, Owner-Execute, Other-Read, Other-W and Other-X. Segments also have a Sharing-Level which is: Activity, Program, Application and Exec/System. Exec/System is normally combined with Other-Access: None, Application is normally combined with Read+Execute.
How much damage is caused each year because the 32-bit I386 architecture cannot supply a reasonable security framework at a reasonable overhead? If the AMD 64-bit processors are capable of fixing this mess, then the GLIBC maintainers could start looking at (optionally?) allowing a safer implementation by separating Code and Data. If this incurs memory-overhead, server farms should be migrating to 64-bit processors anyway by the time such a feature became available. They could also always compile the libraries without that feature.
Mielipiteet omiani - Opinions personal, facts suspect.
It would seem to me that it's clear this patch is much more than just a non-executable stack patch. I think an important point is that while it isn't perfect, if this becomes a standard part of Linux then we can stand on the shoulders of this and tackle the next set of problems. Eventually we may get there.
If we wait until a perfect patch presents itself we will never get there. F.E. using this patch will bring to light all applications that require gcc trampolines. With time, perhaps all of the trampoline code will be replaced - several articles have been written on how to live without trampolines, perhaps this would be the push needed to change.
Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ (Java Web Startable)
Programs compiled for the x86 architecture may well assume that they don't have to set the executable bit on pages because the hardware doesn't support it anyway. Whether such programs are "correct" or not, this patch may break applications.