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.'"

Comments

grsec ?

[destiney]

Sounds like much of the same security that's been available from grsecurity.net for quite a while now.

This is good.

[dracocat]

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.

Possible Problem

[Sunlighter]

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...

Non-executable stacks are part of the solution

[larryjoe]

Reading the announcement for Exec Shield, I can see that the author is aware of the work of Solar Designer, who released the first non-execuable stack solution many years ago. However, I don't see any mention of PaX, which extends the the Openwall solution to other memory regions.

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