Date: Tue, 5 Jul 2005 17:39:33 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: freebsd-hackers@FreeBSD.org Subject: ProPolice symbols in libc or libssp ? Message-ID: <20050705153933.GP73907@obiwan.tataz.chchile.org>
next in thread | raw e-mail | index | archive | help
Hi hackers,
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
compat libc.
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.
Best regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050705153933.GP73907>