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.
prevent people from logging into X as root and screwing up their system.
A cure for stupidity is a many-splendored thing - Publius Julius Caesar on the day before the ides of March ## B.C.
Two stories today with reasons to switch to linux. First IE dies with simple HTML (But really is it any surprise that this is possible) and now a sweet knewe patch for linux. Could it be any better?
"It is not how things are in the world that is mystical, but that it exists." -Ludwig Wittgenstein
http://people.redhat.com/mingo/exec-shield/ANNOUNC E-exec-shield
./cat-lowaddr /proc/self/maps /lib/ld-2.3.2.so /lib/ld-2.3.2.so /lib/libc-2.3.2.so
_____________________________________________
[Announcement] "Exec Shield", new Linux security feature
We are pleased to announce the first publically available source code
release of a new kernel-based security feature called the "Exec Shield",
for Linux/x86. The kernel patch (against 2.4.21-rc1, released under the
GPL/OSL) can be downloaded from:
http://redhat.com/~mingo/exec-shield/
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.
Background:
-----------
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.
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.
This problem has been addressed in the past by various kernel patches,
such as Solar Designer's excellent "non-exec stack patch". These patches
mostly operate by using the x86 segmentation feature to set the code
segment 'limit' value to a certain fixed value that points right below the
stack frame. The exec-shield tries to cover as much virtual memory via the
code segment limit as possible - not just the stack.
Implementation:
---------------
The exec-shield feature works via the kernel transparently tracking
executable mappings an application specifies, and maintains a 'maximum
executable address' value. This is called the 'exec-limit'. The scheduler
uses the exec-limit to update the code segment descriptor upon each
context-switch. Since each process (or thread) in the system can have a
different exec-limit, the scheduler sets the user code segment dynamically
so that always the correct code-segment limit is used.
the kernel caches the user segment descriptor value, so the overhead in
the context-switch path is a very cheap, unconditional 6-byte write to the
GDT, costing 2-3 cycles at most.
Furthermore, the kernel also remaps all PROT_EXEC mappings to the
so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
addresses are special because they cannot be jumped to via ASCII-based
overflows. E.g. if a buggy application can be overflown via a long URL:
http://somehost/buggy.app?realyloooooooooooooooooo oong.123489719875
then only ASCII (ie. value 1-255) characters can be used by attackers. If
all executable addresses are in the ASCII-armor, then no attack URL can be
used to jump into the executable code - ie. the attack cannot be
successful. (because no URL string can contain the \0 character.) E.g. the
recent sendmail remote root attack was an ASCII-based overflow as well.
With the exec-shield activated, and the 'cat' binary relinked into the the
ASCII-armor, the following layout is created:
$
00101000-00116000 r-xp 00000000 03:01 319365
00116000-00117000 rw-p 00014000 03:01 319365
00117000-0024a000 r-xp 00000000 03:01 319439
0024a000-00
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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
the patch was designed to be as efficient as possible. There's a very minimal (couple of cycles) tracking overhead for every PROT_MMAP system-call, plus there's the 2-3 cycles cost per context-switch.
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
You're forgetting XBill.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
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
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.
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?!
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.
(As I'm sure you can tell) I don't claim to know much about any of this at all, but I did read the kerneltrap post, for what it was worth, and as a non-x86 user, I have a few questions. Ingo's patch is only for x86; is equivalent protection for other architectures possible, or even necessary? To what extent are buffer-overflow exploits architecture specific?
Sorry if I'm missing something simple here.
Quoting from the README: Non-executable user stack area.
Most buffer overflow exploits are based on overwriting a function's return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit.
Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system(). This patch also changes the default address that shared libraries are mmap()'ed at to make it always contain a zero byte. This makes it impossible to specify any more data (parameters to the function, or more copies of the return address when filling with a pattern), -- in many exploits that have to do with ASCIIZ strings.
However, note that this patch is by no means a complete solution, it just adds an extra layer of security. Many buffer overflow vulnerabilities will remain exploitable a more complicated way, and some will even remain unaffected by the patch. The reason for using such a patch is to protect against some of the buffer overflow vulnerabilities that are yet unknown.
My name is Igno Molnar
You kill -9 my ppid
prepare to die!
It's against the 2.4.21-rc1 kernel, not 2.4.20-rc1.
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...
... assuming that the stack memory is marked as executable in the binary - which will have the net effect of turning off the Exec-shield.
In other words, ELF format has flags to indicate if the stack should be readable and/or executable. If your doing that sort of thing, make sure that the flag is set, and you'll have no problems [0].
It your doing those sort of tricks, your probably being very careful with what goes where, and buffer lengths and such. The problems come in when people don't realise that there could be a problem, and don't audit the buffer handling code properly.
So, don't worry, just use the ELF flags.
[0] Well, you could set the feature to ignore what the binary says, and implement the security anyway. But that's not a good idea, and very much not default.
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
Maybe I'm missing something really simple, but here's my understanding:
1) x86 stack grows from high addresses to lower ones, allowing for a string allocated on the stack to overflow such that it overwrites the return address.
2) x86 is little-endian which means that the return address (in this case, on the stack) starts with the low byte and stops with the high byte.
3) In C programs, strings are null-terminated.
The ASCII shield relies on ASCII not being able to represent certain addresses, namely 0x00000000 to 0x0100ffff.
Well, here's what I don't get. Assuming all three above, there are five possibilities we can generate for overwriting an address:
1) All four address bytes are overwritten by ASCII characters generating an address greater than 0x01010101.
2) The first three bytes are overwritten by ASCII characters, and the last one is overwritten by the null terminator. This results in an address between 0x00010101 and 0x00ffffff. This certainly looks like an address within the 16M "armor"
3-5) For (3), we only overwrite three of the address bytes, the first two being ASCII, and the last being NUL, resulting in an address something like 0x??00AAAA, where AAAA is greater than 0x0101. This would require that the attacker know what the upper byte of the address is, which is possible. (4) and (5) represent similar situations.
As far as I can see, this 16M protected region doesn't exist. WHAT AM I MISSING?
Thank you.
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
Economically speaking, it's true. Though I will admit I have no hard numbers to give you.
People have a marginal value for driving dangerously, which is balanced by the marginal cost of that action. Where the two meet (marginal cost -vs- marginal value curve), is how people behave (or drive in this case).
In comes a safety feature. That safety feature reduces the marginal cost of driving dangerously. Thus, the driver is able to "afford" more dangerous driving. ie the equilibrium point where marginal value and marginal cost meets has shifted higher towards dangerous driving.
Thus, in economics theory, the driver will drive more dangerously with additional safety features.
The opposite effect, in the original poster's example, of having a spike come out greatly increases the marginal cost. Thus, the "affordable" point shifts far down towards much safer driving.
Of course... this is fundamental microeconomics, and I'm no expert in economics.
(\(\
(^.^)
(")")
*beware the cute-bunny virus
If and when different pages are used for code and data, since both already use different segment descriptors, the code and data have their own completely isolated address spaces, so trying to invoke a buffer overflow that would cause a "return" to some point in the user-supplied data would actually simply cause a return to the corresponding point in the code page, which is, of course, not actually modified by the application. At best, a buffer overflow could cause a branch to a particular section of the existing program, but would not permit the execution of arbitrary code since in the ideal case, even the kernel code resides in an address space that is invisible to any running application. The most probable upshot of trying to "return" in this fashion would be a segmentation fault, which should result in no more than the application simply terminating with a core dump.
File under 'M' for 'Manic ranting'
Hope that helps!
No. The patch lets the exec-shield be toggled off, and adds no more than 2-3 cycles per context switch. On a current x86 box running a vanilla 2.4 kernel, the maximum number of context switches per second is 100. That's a maximum of 300 cycles a second consumed. The oldest machine I've used running Linux was a 486/66 that a friend had. One of these can do at least 66 million cycles a second. On this elderly 486, there will be slowdown of less than a thousandth of a percent. Given that almost all major Linux applications are written in C, the security payoff is probably worth it. I value efficiency a lot, and even so the elimination of the largest security issue in Linux for less than a thousandth of a percent of the CPU time seems like a pretty good trade.
May we never see th
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.