Summary: | frandom/SSP implementation for glibc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Cory Visi (RETIRED) <merlin> |
Component: | Hardened | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hardened, kaiowas |
Priority: | High | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
frandom-0.8-linux-2.6.patch
glibc-2.3.3_pre20040420.ebuild glibc-2.3.2-propolice-guard-functions-v3.patch glibc-2.3.3-frandom-detect.patch ssp-v6.c glibc-2.3.3_pre20040420.tgz glibc-2.3.3_pre20040420-r1.ebuild ssp.c glibc-2.3.2-r10.ebuild |
Description
Cory Visi (RETIRED)
2004-05-12 10:54:31 UTC
Created attachment 31277 [details]
frandom-0.8-linux-2.6.patch
Created attachment 31278 [details]
glibc-2.3.3_pre20040420.ebuild
Created attachment 31279 [details, diff]
glibc-2.3.2-propolice-guard-functions-v3.patch
Created attachment 31280 [details, diff]
glibc-2.3.3-frandom-detect.patch
Created attachment 31281 [details, diff]
ssp-v6.c
Created attachment 31282 [details]
glibc-2.3.3_pre20040420.tgz
I should mention that I tested this on a development machine that was previously starving for entropy. Even with a healthy audio-entropyd and mic setup. After merely emerging this new glibc, my entropy immediately began increasing steadily and after about 10 mins., reached the maximum poolsize. Nice idea Robert! Great and thanks. I'm thinking here that we should maybe have a USE flag also for the erandom detection. logic is as follows use erandom || myconf=--disable && myconf=--enable This way erandom/frandom can be placed in out baselayout as not everybody will want to run devfsd/udev. Now next thing ;/ I've been in binutils-2.15 land for a while now which pukes every time while building a glibc. I'll switch out to a older binutils and give this all a shot. Also reassigning bug to toolchain@ ok I think I solved the binutils + new glibc bug I had mentioned. Getting a patch put together will just take a bit of time. If your interested in helping there the trick is to disable ASLR in the compiled ld.so ( chpax/paxctl -r ) then remove the bits after it does it locale stuff. Better solution would be to hunt down the problem in dl_main() with it trying to exec code at %eip 0x00000000 I think in reality I wont be able to test this stuff to later tonight to tmw. Till then are we ok with USE= erandom ? Ok I've taken a nice close look at this and I don't think I can merge it as is. I'd like to suggest some changes. 1) leave the orig comments intact. 2) Try to leave the hardcoded 2.3.3/ intact vs the ${REAL_PV} (makes it clearer for us to maintain) 3) Lets drop the +SSP_V="v6" (files/2.3.3/ssp.c is fine) 4) Add your name to the ssp.c 5) Consider adding erandom to IUSE 6) Consider change in ssp.c from HAVE_ to WANT_ Created attachment 31434 [details]
glibc-2.3.3_pre20040420-r1.ebuild
Ned, I used all your suggestions except the HAVE/WANT change. Let me know if
you need anything else. "erandom" should be added as a local use flag.
Created attachment 31435 [details]
ssp.c
i patched this to compile properly with gcc 3.4, but for some reason the exact same fix isnt working for the ssp.c in glibc-2.3.3_pre20040420... i'm pretty confused here. anyways, the gcc 3.4 fix is in CVS and simply involves marking __guard_setup with the used attribute and default visibility attribute. no idea why this doesnt work with the old ssp.c... any input would be greatly appreciated. Created attachment 32075 [details]
glibc-2.3.2-r10.ebuild
Backport to the current stable version of glibc. Tested for compile/install on
x86. It was not necessary to alter the patches
(glibc-2.3.3-frandom-detect.patch,
glibc-2.3.2-propolice-guard-functions-v3.patch, ssp.c) in any way; they can be
re-used for this version.
I want to get this into the tree. I've just been lacking time to confirm it builds. Any other devs can do a trial run and test? (pretty please) well, i hopped into chroot to test this and it works fine on amd64 with hardened gcc 3.3.3-r5: ayanami / # /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.3 20040412 (Gentoo Hardened Linux 3.3.3-r5, ssp-3.3-7, pie-8.7.5.3). Compiled on a Linux 2.4.21 system on 2004-06-02. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bugs@gnu.org>. ayanami / # readelf -s /lib/libc.so.6 | grep guard 695: 0000000000233088 8 OBJECT GLOBAL DEFAULT 27 __guard@@GLIBC_2.3.2 851: 000000000001dac0 141 FUNC GLOBAL DEFAULT 11 __guard_setup@@GLIBC_2.3.2 i'll test with gcc 3.4 next <Merlin> i'm not sure testing for the guard function is enough <Merlin> i think you need to look for stack_smash at least alrighty, here it is: ayanami / # readelf -s /lib/libc.so.6 | grep smash 309: 000000000001db50 678 FUNC GLOBAL DEFAULT 11 __stack_smash_handler@@GLIBC_2.3.2 Ok, I'm frustrated as to how to actually check that /dev/erandom is being used. Here's a couple ideas. First of all, I was checking during development by doing an ebuild install and looking in: /var/tmp/portage/glibc-###/work/glibc-###/buildhere/csu I would then do: nm ssp.o | grep sysctl This should demonstrate that the frandom code is being used. Alternatively, you could look in your kernel log file for: May 11 21:15:48 dms1 kernel: frandom: Seeded global generator now (used by erandom) This should appear towards the end of the kernel boot messages. I'm not sure how good of a test this is, though. Anyone have a better method? it wont compile with gcc 3.4, but that's something i already expected. oh well: gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux-x86-64.so.2 -B/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/ -B/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/csu/ -B/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/ -Wl,--version-script=/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/libpthread.map -Wl,-soname=libpthread.so.0 -Wl,-z,combreloc -Wl,--enable-new-dtags,-z,nodelete -Wl,--enable-new-dtags,-z,initfirst -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/math -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/dlfcn -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nss -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nis -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/rt -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/resolv -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/crypt -L/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads -Wl,-rpath-link=/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/math:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/dlfcn:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nss:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/nis:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/rt:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/resolv:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/crypt:/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads -o /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libpthread.so -T /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/shlib.lds /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/csu/abi-note.o -Wl,--whole-archive /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libpthread_pic.a -Wl,--no-whole-archive /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf/interp.os /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libc.so /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/libc_nonshared.a /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/elf/ld.so /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.text+0x0): In function `dummy': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:14: multiple definition of `dummy' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.text+0x0):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:33: first defined here /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.text+0x20): In function `_init': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:25: multiple definition of `_init' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.text+0x20):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:55: first defined here /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.init+0x10): In function `_fini': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:20: multiple definition of `_fini' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.init+0x10):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:39: first defined here /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.o(.init+0x15): In function `_fini': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crti.S:86: warning: undefined reference to `i_am_not_a_leaf' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.init+0x19): In function `_fini': /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:65: warning: undefined reference to `i_am_not_a_leaf' /var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.o(.init+0x1e):/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/crtn.S:66: warning: undefined reference to `i_am_not_a_leaf' collect2: ld returned 1 exit status make[2]: *** [/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/buildhere/linuxthreads/libpthread.so] Error 1 make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2/linuxthreads' make[1]: *** [linuxthreads/others] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.2-r10/work/glibc-2.3.2' make: *** [all] Error 2 !!! ERROR: sys-libs/glibc-2.3.2-r10 failed. !!! Function src_compile, Line 506, Exitcode 2 !!! (no error message) Ned has helped me rediscover the obvious haha... to QA this ebuild/patch properly, please build glibc with USE="frandom" since it is not enabled by deafult (because it does theoretically reduce security). Then simply strace a binary and look for: open("/dev/erandom", O_RDONLY) = 3 read(3, "\323\320}\271", 4) = 4 close(3) = 0 Hopefully, the bytes being read will be different for you (otherwise we have a larger problem :). Ok good. And in a chroot you see the calls to sysctl() ? No bug reports.. Seems to be working great. And you on your way to being able to help maintain this long term. thanks.. Closing bug as FIXED |