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

[Declan Moriarty]

On Sat, 2006-06-24 at 19:04 +0100, paul at clubi.ie wrote:

> > 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.
Yes, actually you are right. Permit me to apologise and unsay that ;-).
It's just the user type perspective - the system jumps in and says "I'm
not falling for that one" and the user presumes it's the kernel. 

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

Sure, that is done. Very effectively usually, with things
like /dev/erandom (properly applied).
> 
> > 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.

But unless you know the system intimately at a code level, you won't
have a great idea of what those bits of the system are, will you?
Hence the all or nothing approach is best. Or, you could grok all the
code...

And the biggest word in there was the "IF". I think it extremely
unlikely that a vanilla gcc-4.1 will compile on any sort of an old
system. They seem to be using very recent kernel headers and binutils
versions to get it going. 

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

The kernel has it's own stack protection which supersedes SSP. I believe
there is a patch that allows -fstack-protector-all(the option to enable
ssp) to be passed to the kernel compilation,  but it still uses the same
ssp as before, and effectively ignores the option.

I knew I was never going to get away with giving a lecture on compilers
here. But the corrections always add to the general pool of knowledge.

-- 
        With Best Regards,

        Declan Moriarty.