ProPolice symbols in libc or libssp ?

[Jeremie Le Hen]

On Tue, Jul 05, 2005 at 05:39:33PM +0200, Jeremie Le Hen wrote:
> 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.

I implemented libssp to circumvent the above problem without thinking
that, in fact, this would not help at all.  Binaries compiled for
older FreeBSD branches (such as RELENG_4) won't indeed be linked
against libssp anyway :).

If someone who has the ProPolice patch installed (and on by default)
compiles ports/misc/compat4x, the latter will be protected and will
therefore require __guard and __stack_smash_handler symbols.  However
since the older binary will have not been linked against libssp, the
symbols won't be found.  In fact, the same thing will happen too for
native binaries that have been built before the ProPolice patch being
applied on the source tree.

Being full of enthusiasm, I checked if by chance libraries could have
dynamic object dependencies.  It appears this is not the case, but
since I'm neither a GCC nor binutils hacker, maybe there is a way to
achieve this.  This is the purpose of this email ?

Is it possible to tell that a library needs other shared objects to
run ?  If yes, how do I do this ?  Is there another way I didn't
think about to circumvent this problem ?

Advices are *very* welcome.

Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >