ProPolice symbols in libc or libssp ?
Jeremie Le Hen
jeremie at le-hen.org
Tue Jul 5 15:39:28 GMT 2005
I'm still working on integrating the ProPolice patch in FreeBSD CURRENT.
A small reminder :
The ProPolice patch prevents from stack-based buffer overflows
but setting a canary between character arrays and the return
address stored in the stack. In addition, automatic variables
are reordered so that pointers stands before buffers.
ProPolice (aka Stack Smashing Protector / SSP) needs two symbols to
work correctly ("__guard" which is the canary initialized before main()
is started, and "__stack_smash_handler" which is the function called
when a buffer overflow is detected ; furthermore, a private contructor
is provided to fill __guard). The original patch stores them in libgcc
but since FreeBSD only provides a static libgcc, this will lead to have
those compiled into all binaries, which is not something acceptable, IMO.
Numerous patches porting ProPolice to newer versions of FreeBSD store
these symbols in libc, so they are dynamically linked. That's what I
did too and it worked quite well.
However, Victor Balada Diaz tested the patch for me and reported that
it breaks Opera compiled for RELENG_4 because the latter is linked
against libc (compat one) and libz. The problem is that the libz
version against which Opera is dynamically linked is not residing in
compat/ and _needs_ ProPolice symbols which are obviously not in the
Another solution taht exists, the one used by the Hardened Debian
project, is to have a libssp containing these two symbols.
How would you, hackers, overcome this problem ?
Suggestion are welcome. Thanks.
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
More information about the freebsd-hackers