On Fri, 23 Jun 2006, Declan Moriarty wrote:
> Gcc-4.1 has many security minded features built in, notably SSP.
> Probably he's been reading and wants these.
> SSP prevents this in the kernel.
No. SSP has nothing to do with the kernel. It's simply the insertion
of guard values in the frame 'preamble' to protect the return address
by overflow of variables local to the frame - by having the compiler
emit code to check the guard is still valid when returning from a
(Note that if the guard is a well-known value, and the attacker can
inject full values (rather than say, ASCII restricted ones), the
attacker can defeat SSP easily. I guess though compilers can easily
randomise the guard value somewhat on a per-object file basis.).
The kernel stack-overflow-mitigating feature you're thinking of is
probably 'No Execute' - having the permissions of memory of the stack
be marked 'no execute' so that the basic 'overflow the stack with
injected exploit code and return to it' trick no longer works.
All sane architectures have support for this on a per-page basis.
That left x86 which lacked sufficient bits in page tables. Eventually
someone figured out that segments (which most paged VM OSes tended to
ignore as being archaic on x86) could be used alongside page tables
to approximate ^PROT_EXEC for the stack for x86 CPUs.
With AMD64, x86 gained the required additional per-page permission
bit. Also available in 32bit mode (the NX cpu feature). Intel have
added this to their CPUs too. So more recent x86 CPUs don't need the
> If he compiles against your existing glibc and kernel headers, and
> gets going, he will be able to get ssp protection throughout. But
> only if he compiles throughout.
No, you don't have to compile throughout to gain from SSP.
Code that writes external data to the stack is what gains the most
from SSP. That kind of code typically is in the application, even
where the actual overflow is through use of some 'unsafe' libc
function (e.g. the str family of functions) - which typically are
passed the storage to write to (e.g. a pointer to the stack storage).
Compiling an application with SSP can catch those errors, even where
the libc is not compiled with SSP.
Note that the kernel isn't involved at all - it would make no
difference at all. Further, AFAIK, the Linux kernel can /not/ (yet)
be compiled with SSP.
Note that SSP can not detect heap storage overflows. (However, you
can detect those in the heap allocator). Heap storage is a bit more
difficult to exploit (DoS of the application is easy, but getting the
application to run injected code would be more difficult if SSP is
Paul Jakma paul at clubi.iepaul at jakma.org Key ID: 64A2FF6A
I've only got 12 cards.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!