It's interesting to examine what information about maintainers' build
environments slips into binary packages, and consider the possible
consequences and what, if anything, we can do about it.
Here's an annotated and edited version of the output of the command
strings -f /usr/bin/* /usr/sbin/* /bin/* /usr/lib/* /lib/* /sbin/* | \
egrep '/home/.*/' | sort | uniq
If you're only interested in checking your own packages, I suggest
instead,
for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a $HOME ; done
/sbin/start-stop-daemon: /mount/md0/home/adam/debian/mine/dpkg/v1_10/dpkg-1.10.10/utils/start-stop-daemon.c
# Given the __assert_fail in the symbol table, this is probably
# displayed as part of an assertian. One of the more common cases.
#
# Of course this leaves the user wondering why the program is
# complaining about this "adam" person and his nonexistent home
# directory. Hmm, raid0?
#
# Note that assert only puts the full path to a file in if you give that
# full path to gcc. A minor modification to dpkg's Makefiles would
# convert this into just "utils/start-stop-daemon.c" and save us all a
# few bytes. I'll skip the other ~50 copies in dpkg, dselect, etc.
/usr/bin/WPrefs: /home/marcelo/devel/debian/wmaker/releases/wmaker-0.80.1/WINGs/array.c
/usr/bin/WPrefs: /home/marcelo/devel/debian/wmaker/releases/wmaker-0.80.1/WINGs/data.c
/usr/bin/WPrefs: /home/marcelo/devel/debian/wmaker/releases/wmaker-0.80.1/WINGs/dragsource.c
# I've snipped the other 29 copies of this and even more in
# /usr/bin/WindowMaker. These are more assertians.
/usr/bin/ebrowse.emacs21: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lib-src/ebrowse.c
/usr/bin/ebrowse.emacs21: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lib-src/ebrowse.c
/usr/bin/ebrowse: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lib-src/ebrowse.c
# More asserts.
/usr/bin/emacs21-x: /home/rlb/bin
# Now this is interesting. What is emacs21 doing with rlb's bin
# directory?
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/bin/info
# Maybe it would like to run this program? Apparently not in my testing,
# but that's something new to worry about. I wonder what it does use it
# for.
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lisp
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lisp/loadup.el
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/etc/
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/lib-src
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/lib-src/
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/\2
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/emacs
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/temacs
/usr/bin/emacs21-x: Using load-path (/home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lisp)
# Despite all this, strace does not show it touching /home/rlb at all
# during load or basic use. Emacs is a weird beastie.
#
# Skipping on past many more asserts.
/usr/bin/kismet_drone: @(#) $Header: /home/dragorn/src/CVS/kismet/kismet-devel/libpcap-0.7.2/bpf/net/bpf_filter.c,v 1.1 2003/07/30 00:40:54 dragorn Exp $ (LBL)
# Many copies of this, odd to find it embedded in a binary. So here's
# another common case, probably much more common in debian diffs if anyone
# cares. Although in this case it looks like this is the author's
# homedir, not the developer's.
/usr/bin/latex2html: $TEXEXPAND = "$PERL /home/users/aure/Projets/debian/latex2html-2000-beta1${dd}texexpand";
# This is interesting. If run with an undocumented test_mode switch,
# latex2html does a demo run using hardcoded files and programs inside a
# user's home directory. A two-step social hack is possible, though
# unlikely. I've filed a bug.
#
# Skipping past more asserts and some false positives..
/usr/bin/strobe: ..//home/rcw/src/netdiag-0.7/strobe/debian/tmp/usr/lib/netdiag/strobe.services
# This is possibly exploitable, since it does try to open that file. Of
# course it also tries ./strobe.services, which is more likely to be
# exploitable. Hope that the code used to read the file does not have buffer
# overrun problems. Bug filed.
/usr/bin/ttf2pt1_convert: TTF2PT1_BINDIR=/home/foka/debian/ttf2pt1-3.4.0/debian/ttf2pt1/usr/bin
/usr/bin/ttf2pt1_convert: TTF2PT1_LIBXDIR=/home/foka/debian/ttf2pt1-3.4.0/debian/ttf2pt1/usr/lib/ttf2pt1
/usr/bin/ttf2pt1_convert: TTF2PT1_SHAREDIR=/home/foka/debian/ttf2pt1-3.4.0/debian/ttf2pt1/usr/share/ttf2pt1
# Here we go again. Not only could these be used to run arbitrary code
# as any user who runs ttf2pt1_convert, if your username happens to be
# "foka", but it seems from the comments in the program that these
# are intended to have real directories in them. I wonder if the program
# even works without knowing where its sharedir is. To make this
# really easy the man page lists the above directories with /home and
# all! Bug filed.
/usr/lib/libasprintf.a: /home/sanvila/GETTEXT/gettext-0.12.1/gettext-runtime/libasprintf
/usr/lib/libgdbm_compat.so.3.0.0: /home/james/debian/packages/gdbm/gdbm-1.8.3/.libs
/usr/lib/libgettextpo.a: /home/sanvila/GETTEXT/gettext-0.12.1/gettext-tools/src
/usr/lib/libguile.so.12.3.0: /share/home/sam/debian/nmu/guile/guile-1.6.4
# No idea what this these are, but they do not look like a asserts.
# Some other class of home directory leakage. I see Sam is a hardcore
# NMUer with a dedicated directory..
And that's all for my laptop. Three possible security holes, a few
things I don't understand yet and a disappointing dearth of juicy
details about your private lives. It is interesting to note where
developers keep their packages in their home directories:
debian/devel debian/mine deb debian
devel/debian src/debian p/Debian src/CVS
Projects/debian src deb/my PACKAGENAME
Of course, home directories are just one thing that can get trapped in
a binary. Other likely candidates include the build system's hostname,
which can vary between benign and a real bug. Slrn used to use the build
hostname at runtime when posting articles, for example.
for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a `hostname -f` ; done
Anyway, what can we do about these? Lintian could easily notice if your
$HOME was in a deb, and display warnings (possibly filtering out the
asserts). The assert macro uses __FILE__ to get the filename; maybe
there's some way to convince ccp to make __FILE__ always relative, without
breaking anything, or provide a __RELFILE__ that assert could be changed
to use. Alternatively, you can pass relative filenames to gcc and save a
little space in the binary.
--
see shy jo, a ~/src/packages/ man myself
Attachment:
pgp4AC62NXvBZ.pgp
Description: PGP signature