1 |
Fabian Groffen wrote: |
2 |
> On 15-05-2008 15:25:02 +0200, Markus Duft wrote: |
3 |
> |
4 |
>>> Thanks for the in depth explanation. I'd not be surprised if Solaris |
5 |
>>> actually has the same problem. |
6 |
>>> |
7 |
>> If solaris supports ssp, yes, i think so too. |
8 |
>> |
9 |
> |
10 |
> I think it does support stack smashing protector stuff ;) |
11 |
> |
12 |
> |
13 |
>>> I've no idea of it in the main tree, but since it doesn't even compile |
14 |
>>> on Linux, I'd say, keep it masked. |
15 |
>>> |
16 |
>> Yeah, but maybe disabling the ssp for configure is the right way to |
17 |
>> go, since ssp is explicitly disabled when building gcc. I don't think |
18 |
>> that it will help sitting it out. |
19 |
>> |
20 |
> |
21 |
> gentoo-x86 has to figure this out for sure. SSP is a security thing, |
22 |
> and you don't *ever* want it to be disabled on a thing like SSH if you |
23 |
> enabled it for GCC (like hardened profiles do). |
24 |
> |
25 |
> |
26 |
(Replying to a oldish thread) |
27 |
|
28 |
I've looked a bit more into this, but still not sure what the |
29 |
best/cleanest solution is. |
30 |
|
31 |
Mainline Gentoo has this figured out - the recent glibc packages provide |
32 |
the SSP support. On my gentoo-x86 machine: |
33 |
$ readelf -s /lib/libc.so.6 | grep stack_chk |
34 |
458: 000d4bd0 67 FUNC GLOBAL DEFAULT 11 __stack_chk_fail@@GLIBC_2.4 |
35 |
|
36 |
There are some functions in toolchain.eclass that test glibc for SSP |
37 |
support, and if it finds the right symbols, configures GCC with |
38 |
"--disable-libssp". However, I don't think these tests work quite right |
39 |
for Prefix. My Debian Etch installs where I have Prefix, don't have a |
40 |
glibc with SSP symbols: |
41 |
$ readelf -s /lib/libc.so.6 | grep stack_chk |
42 |
(returns nothing) |
43 |
Yet toolchain.eclass will still configure GCC with "--disable-libssp" |
44 |
there (and again on OpenSolaris, where the system libc doesn't have SSP |
45 |
afaik). |
46 |
|
47 |
With only "--disable-libssp", GCC still accepts the "-fstack-protector" |
48 |
and "-fstack-protector-all arguments", since it only disables the |
49 |
building of the stack smashing protection *libraries*, not SSP itself. |
50 |
Programs will of course fail to link properly if either of these |
51 |
arguments is used. |
52 |
|
53 |
This affects OpenSSH 5.0, because the test code its configure uses to |
54 |
test "-fstack-protector", is too simple to trigger any SSP |
55 |
functionality. For example: |
56 |
|
57 |
simple.c (similar to the configure check) |
58 |
---- |
59 |
#include <stdio.h> |
60 |
|
61 |
int main(int argc, char** argv) |
62 |
{ |
63 |
return 0; |
64 |
} |
65 |
---- |
66 |
|
67 |
$ gcc -fstack-protector -S -o simple.S simple.c |
68 |
$ cat simple.S | grep stack_chk |
69 |
(returns nothing) |
70 |
|
71 |
ssp.c (some unsafe code) |
72 |
---- |
73 |
#include <stdio.h> |
74 |
#include <string.h> |
75 |
|
76 |
int main(int argc, char* argv[]) |
77 |
{ |
78 |
char buffer[25]; |
79 |
strcpy(buffer, argv[1]); |
80 |
|
81 |
printf("%s\n", buffer); |
82 |
|
83 |
return 0; |
84 |
} |
85 |
---- |
86 |
|
87 |
$ gcc -fstack-protector -S -o ssp.S ssp.c |
88 |
$ cat ssp.S | grep stack_chk |
89 |
call __stack_chk_fail |
90 |
|
91 |
So, IMO, the best option would be to modify toolchain.eclass to do a |
92 |
better check for SSP support on the host platform somehow, and |
93 |
--enable-libssp in more situations. If that is too difficult, maybe |
94 |
OpenSSH's -fstack-protector check could be patched so it tries to |
95 |
compile code which will actually force the use of the stack protector. |
96 |
|
97 |
(I've just noticed that OpenSSH 5.1 is out, but I haven't looked at it yet) |
98 |
|
99 |
Matt. |