Fabian Groffen wrote:
> On 15-05-2008 15:25:02 +0200, Markus Duft wrote:
>   
>>> Thanks for the in depth explanation.  I'd not be surprised if Solaris
>>> actually has the same problem.
>>>       
>> If solaris supports ssp, yes, i think so too.
>>     
>
> I think it does support stack smashing protector stuff ;)
>
>   
>>> I've no idea of it in the main tree, but since it doesn't even compile
>>> on Linux, I'd say, keep it masked.
>>>       
>> Yeah, but maybe disabling the ssp for configure is the right way to
>> go, since ssp is explicitly disabled when building gcc. I don't think
>> that it will help sitting it out.
>>     
>
> gentoo-x86 has to figure this out for sure.  SSP is a security thing,
> and you don't *ever* want it to be disabled on a thing like SSH if you
> enabled it for GCC (like hardened profiles do).
>
>   
(Replying to a oldish thread)

I've looked a bit more into this, but still not sure what the 
best/cleanest solution is.

Mainline Gentoo has this figured out - the recent glibc packages provide 
the SSP support. On my gentoo-x86 machine:
$ readelf -s /lib/libc.so.6 | grep stack_chk
458: 000d4bd0    67 FUNC    GLOBAL DEFAULT   11 __stack_chk_fail@@GLIBC_2.4

There are some functions in toolchain.eclass that test glibc for SSP 
support, and if it finds the right symbols, configures GCC with 
"--disable-libssp". However, I don't think these tests work quite right 
for Prefix. My Debian Etch installs where I have Prefix, don't have a 
glibc with SSP symbols:
$ readelf -s /lib/libc.so.6 | grep stack_chk
  (returns nothing)
Yet toolchain.eclass will still configure GCC with "--disable-libssp" 
there (and again on OpenSolaris, where the system libc doesn't have SSP 
afaik).

With only "--disable-libssp", GCC still accepts the "-fstack-protector" 
and "-fstack-protector-all arguments", since it only disables the 
building of the stack smashing protection *libraries*, not SSP itself. 
Programs will of course fail to link properly if either of these 
arguments is used.

This affects OpenSSH 5.0, because the test code its configure uses to 
test "-fstack-protector", is too simple to trigger any SSP 
functionality. For example:

simple.c (similar to the configure check)
----
#include <stdio.h>

int main(int argc, char** argv)
{
    return 0;
}
----

$ gcc -fstack-protector -S -o simple.S simple.c
$ cat simple.S | grep stack_chk
(returns nothing)

ssp.c (some unsafe code)
----
#include <stdio.h>
#include <string.h>

int main(int argc, char* argv[])
{
    char buffer[25];
    strcpy(buffer, argv[1]);

    printf("%s\n", buffer);

    return 0;
}
----

$ gcc -fstack-protector -S -o ssp.S ssp.c
$ cat ssp.S | grep stack_chk
        call    __stack_chk_fail

So, IMO, the best option would be to modify toolchain.eclass to do a 
better check for SSP support on the host platform somehow, and 
--enable-libssp in more situations. If that is too difficult, maybe 
OpenSSH's -fstack-protector check could be patched so it tries to 
compile code which will actually force the use of the stack protector.

(I've just noticed that OpenSSH 5.1 is out, but I haven't looked at it yet)

Matt.