[ILUG] Can anyone see any reason why a customer would need to compile a new compiler?

[paul at clubi.ie]

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

(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 
segment hack.

> 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 
also enabled).

regards,
-- 
Paul Jakma      paul at clubi.ie   paul at jakma.org  Key ID: 64A2FF6A
Fortune:
I've only got 12 cards.