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.
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
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.
To change the starting virtual address of a binary, just change the linker script (or use a command-line option to the linker). Why did they have to patch binutils?
They could also link with "--emit-relocs" to leave the relocations in the binary. Then it could run in low memory or at the usual address (0x8048000).
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.
Its surprising what you can find out there if you look. Just last month, I was pointed to an installer+binary for running Serious Sam: The First Encounter under Linux. Plays like a dream.
Inconceivable!
is this a patch i should have installed on my various linux servers? I understand any new code should be tested on a development server before being moved to production, but assuming this patch doesnt cause any problems, is it something thats worth the time and effort to help reduce buffer overflows ?
Lawyers, MBA's, RIAA? A jedi fears not these things!
There are two reasons why this kind of patch would require recompilation.
One (implied in the linux-kernel post) is that it would be nice to fix the ELF format and remove the assumption that the stack can contains executable code. Also, changing the way the program is laid out in memory affects security (see the "ASCII Armour" bit). A priori you might think that recompilation (producing a new binary) would be required for that.
The second is self-modifying code. Some application (the post mentions XFree86) want to have parts of the binary decided upon at runtime (mostly for optimization purposes). For that to work you need to know which parts of the memory are accessible both for writing (as data) and execution (as code). If the rules for that change (which is the point of patches like this one), you'll have to do even more than recompile -- such software will have to be fixed!
Getting X to work without recompilation (in fact, without patching) was a real issue -- read the explanation of the "X-workaround" hack.
hope this helps,
Lior
Use grsecurity with all address space randomizations on and it'll be very difficult to guess correct address. I think that required recompiling the binaries though.
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 have looked at WineX, the problem with it is that it takes individual upgrades for specific games. It's just me, but I'd rather see native support for the individual titles than getting emulated support for the titles, which adds an unnecesary proccessing layer to the system. I know I'm getting flamed for up above, but I support Linux.
I want Linux to succeed more than anything, because I love some of the things that it does. KDE and Gnome both blow away Windows from the level of usefullness and power, and the control and security of Linux are awesome. But the programs I use the most, Bryce 5, Photoshop, and MS Office, are Windows only, and the competing applications are just not up to where they are.
Blender has a learning curve steeper than everest, and I'd have to program my own lab plugins to do the work I do now. Gimp is a good program, but 6 years of work with Photoshop have made me dependant. And Office is still the best of Microsofts programming.
I may do the switch soon though, because I'm taking up PHP coding for web application deployment and programming. So we'll see.
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.
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
Protected/virtual address spaces help avoid a plethra of security/stability issues. Does this mean in your opinion that such virtual addressing encourages sloppy programming?
--adam
If you use linux with BIG_MEM (3GB/1GB split) enabled in the kernel, your .text segment is allocated starting at 0x00010000. I forget why but there was some simplicity to using the 1GB/1GB split otherwise on linux (.text starting at 0x80000000, kernel mem at 0xc0000000). Windows uses a default 2GB/2GB split, so it makes sense it would start at 0x0. I don't think they were thinking about ASCII armor when they made that decision in the NT 3.x days.
Fuck Beta. Fuck Dice
You know.. you may be right.. consider this little program. It is a series of characters in an array.. the characters are 0x01,0x01,0x01,0x00 (as was your case (2)). When you print this out as an int, you get 65793. This is certainly less than 16 million.
#include <stdio.h>
#include <string.h>
int main(void)
{
char arr[sizeof(int)] = { 0x01, 0x01, 0x01, 0x00 };
printf("%d\n", *((int *)arr));
return 0;
}
So I don't get what Ingo means when he says that this region is somehow ASCII-shielded... because you are right.. on the x86 the high order byte is last, not first (as was the assumption in Ingo Molnar's little readme).
What GIVES??! Anyone? What am *I* missing?
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
What happens if an executable maps in more than 16mb of shared libraries? Will one of these libraries get mapped to NULL? Or will it forgoe security for actually working?