Contributed by
Dengue
on
from the dont-forget-the-static-binaries dept.
Bill Schaub
writes :
"Patches have been released for the fts libc functions.
It is possible to trick a program traversing a directory structure to go outside of that directory structure.
the patch is at
ftp://ftp.openbsd.org/pub/OpenBSD/patches/2.9/common/002_fts.patch
. The patch tells you to apply the patch and recompile libc but it neglects to tell you about staticly compiled binaries. (hint /bin and /sbin and a few binaries in /usr/bin /usr/sbin and /usr/libexec)"
We
posted
the patch notice already, but Bill's remarks about static binaries bear mention. Also, thanks go out to Joshua Stein for the 2.9 topic icon.
-ed
(Comments are closed)
Comments
By
Anonymous Coward ()
on
I have to recompile those statically linked binaries, too?
People not choosing to upgrade with a make build, don't forget to recompile libc_r as well. Nothing in the base system uses it, but you might have installed ports which make use of it.
By
Anonymous Coward ()
on
Could I just make/install libc then make/install everything in /usr/src, just to make sure I have everthing?
Im sorry for reposting this but after replying inside of a thread i decided to make this more visible to people reading the article.
IMHO recompiling staticly linked binarys that possibly use the affected libc function should be included in any libc security patch instructions.
take the fts patch for example lots of bianrys that use fts(3) reside in /bin and /sbin i know the FreeBSD advisory had a list of programs to
recompile for the same reasons (staticly linked)
now for instructions:
after applying the fts patch, build and install libc as the patch instructs. then go to the /usr/src/bin, /usr/src/sbin, /usr/src/libexec, /usr/src/gnu/usr.bin/gzip, /usr/src/usr.bin and /usr/src/usr.sbin directorys and do "make obj; make depend; make; make install;" in each of these directorys.
This should take care of all staticly compiled binarys. i could dig up a list of everything thats static but i cant be fscked. im still wondering why there is anything in /usr/libexec, /usr/bin and /usr/sbin that are staticly linked at all. since /usr/lib is mounted by the time you get to execute anything in those directorys anyway.
I hope this helps, i just wanted to make sure nobody got burned by this since staticly linked binarys have libc (and other librarys linked in with the -l flag)linked physically into the binary instead of pulling anything in from /usr/lib at runtime.this allows certain programs to run without the library files (think /bin and /sbin before /usr is mounted at boot time) this is why you need to recompile these binarys when you change security related functions in libc
because they wont load libc at boot time and retain thier own static image of libc from the time they were first compiled. i hope this clears up any confusion.
by the way please dont flame me for not preparing a list of all staticly linked code that uses fts
instead of having people recompile everything thats staticly linked. i really didnt have the time and didnt want to confuse people more than i had to.
I emailed Todd Miller and he told me that the patch should indeed mention static binaries, so he will make a list of effected things and amend the instructions.
By Anonymous Coward () on
By Miod Vallat () miod@openbsd.org on mailto:miod@openbsd.org
By Anonymous Coward () on
Could I just make/install libc then make/install everything in /usr/src, just to make sure I have everthing?
By Jeff Flowers () jeff@jeffreyf.net on http://www.jeffreyf.net
By Bill Schaub () on
IMHO recompiling staticly linked binarys that possibly use the affected libc function should be included in any libc security patch instructions.
take the fts patch for example lots of bianrys that use fts(3) reside in /bin and /sbin i know the FreeBSD advisory had a list of programs to
recompile for the same reasons (staticly linked)
now for instructions:
after applying the fts patch, build and install libc as the patch instructs. then go to the /usr/src/bin, /usr/src/sbin, /usr/src/libexec, /usr/src/gnu/usr.bin/gzip, /usr/src/usr.bin and /usr/src/usr.sbin directorys and do "make obj; make depend; make; make install;" in each of these directorys.
This should take care of all staticly compiled binarys. i could dig up a list of everything thats static but i cant be fscked. im still wondering why there is anything in /usr/libexec, /usr/bin and /usr/sbin that are staticly linked at all. since /usr/lib is mounted by the time you get to execute anything in those directorys anyway.
I hope this helps, i just wanted to make sure nobody got burned by this since staticly linked binarys have libc (and other librarys linked in with the -l flag)linked physically into the binary instead of pulling anything in from /usr/lib at runtime.this allows certain programs to run without the library files (think /bin and /sbin before /usr is mounted at boot time) this is why you need to recompile these binarys when you change security related functions in libc
because they wont load libc at boot time and retain thier own static image of libc from the time they were first compiled. i hope this clears up any confusion.
by the way please dont flame me for not preparing a list of all staticly linked code that uses fts
instead of having people recompile everything thats staticly linked. i really didnt have the time and didnt want to confuse people more than i had to.
By Jeff Flowers () jeff@jeffreyf.net on mailto:jeff@jeffreyf.net
Jeff