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.'"
Sounds like much of the same security that's been available from grsecurity.net for quite a while now.
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
While of course all of our software should be correct, using the Operating System to make software more robust is almost always a good thing.
Assuming their claims of extremely low over-head are true, why would we not want this?
In fact, a lot of security issues could be stopped before they ever happen if we look more closely at the Operating System instead of all the software! Think how much easier it would be to work on isolating software and protecting the system from itself than trying to make every single app ever written secure. Yes, focusing attention to the Operating System for vulerabilites is a good step--even though we can't ignore our applications.
You do realise this kind of advancement would not be possible with out assistance from highly successful companies like SC...
Hrm...
"Shit, spaceballs, there goes the planet" --apes
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Another saturday night spent on
Someone on lkml asked:
Slightly off-topic, but does anybody know whether IA64 or x86-64 allow you to make the stack non-executable in the same way you can on SPARC?
and hpa replied to this:
x86-64 definitely does, and it's the default on Linux/x86-64.
Up to now, x86 chips have not been able to separate Read from Execute privileges for memory segments, which makes it hard to make stacks non-executable. This is excellent news for anyone looking forward to AMD's x86-64 chips...it keeps looking like they've done the Right Things.
I've written a few pieces of code which take advantage of the executability of the stack and the heap. For example if you want to write a just-in-time compiler for some language, an easy way to do it is allocate an area on the heap, let the JIT compiler write the appropriate x86 machine code into that area, and then typecast the area pointer to a function pointer and execute it.
With this patch, that won't work...
Sunlit World Scheme. Weird and different.
The limitation is with most x86 processors. The new AMD x86-64 architecture does not suffer from this problem, and I believe linux on it defaults to nonexecutable stack (at least that's what was said on the LKML).
My name is Igno Molnar
You kill -9 my ppid
prepare to die!
While it is true that in general even HUGE changes to the kernel rarely need an application recompile, and are transparent, sometimes this is not the case.
Consider the following:
Actually, even this patch is not entirely transparent. In order to best benefit from the ASCII-armor area, you will notice that in the readme text file they actually gave a patch to binutils to make executables try and use a lower address for their program text. Executables (unlike shared libraries) aren't relocatable and thus need to be re-linked in order to use a different (lower) address...
It should also be pointed out that while most buffer overflow exploits do indeed simultaneously overwrite the return address and inject the shellcode onto the stack, a certain class of buffer overflow exploits called return-into-libc attacks do not require executable stacks and are not too difficult to construct. These attacks overwrite the return address with the starting address for one of the libc exec*() functions. At the same time, the parameters for executing /bin/sh are pushed onto the stack. The execution of the corresponding return instruction then causes the exec*() function to execute /bin/sh. See this paper for a more detailed analysis of some buffer overflow solutions.
I think that it's interesting that in the past few weeks, several solutions for buffer overflows have been announced (e.g., the OpenBSD announcements). Each of these solutions are good solutions, but they heavily borrow from earlier solutions. Unfortunately, the previous work has often not been properly acknowledged. Since the masses are generally not aware of the current state of the art, these supposedly new solutions are given more credit than due. Still, I suppose it's a good thing if general awareness of the buffer overflow problem is raised, even if the pioneers of the technology do not receive their due credit.
Tim Tsai
I've been screwing around with mprotect() and friends lately to write a exploit delivery system that can't be read by memory inspection tools on the target machine. While checking to see if similar techniques are possible on Windows, I found that the default addresses for PE/i386 executables' stack and text sections are all below 0x00ffffff. .text begins at 0x00400000, for example, and the stack is located below it.
:) I was wondering for the longest time why they chose those mappings by default until I saw this article today.
So it looks like Microsoft beat Ingo to it
-- thalakan
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.
No. The x86 page table has 12 bits per page table entry for storing page information. It contains a bit for R/W (read/write) which you can force a page read-only; and it contains a bit U/S (user/supervisor) which you can force a page usable only by the kernel. There is nothing which says "this page must not be executed as code". So Linux kernel actually has an interface that only some hardware provides. I don't think now it still has spare bit to give for executable bit.
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.
It is not about "do the right thing". The processor simply has no such bit, so there is no new "right thing" for it to do---it is already doing the right thing. The processor assumes that segmentation is used to enforce execute permission, so that each library code should be allocated a segment and inter-segment jumps and calls should be used to access them. In such way only read-only code segments are executable. Linux simply decided at the very beginning not to employ this facility.
ELF is not designed by Linus. And even if ELF is changed so that stack is not assumed executable by default (which probably break some programs that rely on executable stack), all computers from 386 to P4 will not benefit from it.