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
pgpNF5TiluTEs.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
