RE: Secure 2.4.x kernel
> Now heres my next questions and its a security one.
> Based off what was explained by Noah and Kelly,
> it appears to me that Buffer Overruns can be dealt
> with at the kernel level and that there is probably
> a way in the kernel to stop a root exploit during
> a buffer overrun. Why hasn't (or maybe someone has)
> someone come up with a "ring" or security layer that
> protects against root exploits on buffer overruns?
It is possible to detect heap buffer overruns with the virtual memory
hardware. There's a library (called "electric fence") for doing this, in
fact. However, doing this requires that you put each buffer in a memory
page of its own, and further that you leave a blank (unmapped) page on each
side of the buffer. Since most buffers are less than a VM page, this causes
your memory usage to explode. This sort of environment is suitable for
testing, but most definitely not suitable for production. Also, this
technique does not work for stack overruns, which is the sort of buffer
overrun that leads to an exploit. (Heap overruns virtually always cause the
application to simply crash. It is probably not possible to reliably use a
heap overrun to execute arbitrary code the way one can use a stack overrun.)
It is my opinion that doing stack protection is probably impossible with the
Intel i386 architecture. In theory, it's possible, but I haven't seen a
processor in common use that could do it.
A better approach, as you note, is to use a more refined privilege system
than UNIX has to circumscribe the damage when a stack overrun exploit
occurs. Taking away the fork and exec syscalls from a daemon which does not
need to do either would be a good start.
Kelly
Reply to: