Glibc/SSP notes

Robert Connolly robert at linuxfromscratch.org
Sun May 13 19:46:55 PDT 2007


Currently, between filtering for -D_LIBC_REENTRANT, -DHAVE_INITFINI, etc, the 
Glibc package gets little or no -fstack-protector protection.

In the last few days I have been trying many things, including adding 
stack_chk_fail_local.o* to ld.so and libc.so, adding dummy 
__stack_chk_fail_local functions to rtld.c, and it's looking like libc.*, 
ld.so, and libmemusage.*, can not build with -fstack-protector-all. Before 
ssp was moved to TLS, they could. Having stack_chk_guard in TLS is a pretty 
good improvement because the guard value is set for each thread, rather than 
per program execution, but this also uses far more entropy than before and 
makes erandom more important than ever.

If ld.so is compiled with -fstack-protector* it will segfault. I did manage to 
build libc.so with -fstack-protector-all, and the test suite passes for 
dynamically linked tests, but anything linked to libc.a statically will 
crash. This isn't healthy, so the next best thing is to 
disable -fstack-protector for ld.so and libc, and use -fstack-protector-all 
on the extra-libs and programs. The _FORTIFY_SOURCE protection would have 
similar issues, so whereever -fno-stack-protector is, -D_FORTIFY_SOURCE=0 
probably also be needed.

The kernel patches for SSP have traditionally used a static guard value, but 
with erandom we can use erandom_getbytes from within the kernel. I'm not sure 
this will actually add any protection, but it was added to the mainline 
kernel for x86_64, so it's worth checking it out again for x86. The patches 
and discussion for the x86_64 kernel patch didn't seem to include a proof of 
concept.

Furthermore, Glibc has designed their SSP code as a debugging feature, not a 
security feature. The failure routines could be improved by blocking signals 
before doing an abort, and logging to syslog. Gentoo has modified their 
stack_chk_guard.c to use inline syscalls, so stack_chk_guard.c doesn't have 
any functions itself (so it can compile with -fstack-protector without 
causing a circular dependency). Something similar should also be done for all 
the files in glibc-2.5/debug/, so _FORTIFY_SOURCE is hardened a bit better. 
Doing this with libmudflap would also be a good idea.

I made a new patch for GCC, so pie, ssp, fortify_source, and mudflap 
modifications are each separate and optional. Making this work with Glibc is 
not difficult... -fno-stack-protector and -D_FORTIFY_SOURCE=0 doesn't make a 
difference if you're not using them to begin with. -pie can be detected by 
Glibc's ./configure, and so can #ifdef __PIC__. I removed -fpic from the new 
GCC patch because pretty much any package that doesn't make their shared 
libraries pic needs a patch regardless of whether -fpic is used, so the patch 
should add -fpic instead of the GCC specs. This affects a handfull of 
graphical packages, like mesa-lib. I'm making sure this patch works with 
Glibc before releasing it.

For a wishlist idea, I've also been thinking it'd be nice if SSP could be 
disabled on a per function basis, with "#undef __SSP__".

I sent a patch last week to Binutils bugzilla to add --error-shared-textrel. 
This is like --warn-shared-textrel, except it causes a fatal error. This 
seemed more sensible to me than patching --warn-shared-textrel to be fatal.
It also came to my attention that the '-z lazy' patch doesn't rebuild the 
manual and info pages to reflect the new option... but instead of 
using --enable-maintainer-mode, the manual and info pages can simply be 
removed before building Binutils and they will be rebuilt during 'make' and 
will add the new options. I haven't tried this out in the early chapter6 
environment, but it should work with Gettext and Texinfo in /tools (it may 
need a full install of Gettext).

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070513/d876f628/attachment.sig>


More information about the hlfs-dev mailing list