Re: imformation leakage in debian binaries

2003-09-08 Thread Adam Heath 
On Sat, 23 Aug 2003, Joey Hess wrote:

 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.

I've thought about doing this for dpkg's build system, before, because of the
long path that is encoded.

I'll probably be part of dpkg 2.0.

Re: imformation leakage in debian binaries

2003-09-08 Thread Adam Heath 
On Mon, 8 Sep 2003, Adam Heath wrote:

 On Sat, 23 Aug 2003, Joey Hess wrote:

  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.

 I've thought about doing this for dpkg's build system, before, because of the
 long path that is encoded.

 I'll probably be part of dpkg 2.0.

Ok.  I have it fixed.

bash-2.05b$ strings build/src/lib/tests/hashtable-test |grep hashtable-test.c
../../../src/lib/tests/hashtable-test.c

I might be able to fix it even better, by overriding __FILE__ myself(with -D)
on the cmdline, instead of letting it be filled in by cpp from -c.

Re: imformation leakage in debian binaries

2003-09-08 Thread Adam Heath 
On Mon, 8 Sep 2003, Adam Heath wrote:

 Ok.  I have it fixed.

 bash-2.05b$ strings build/src/lib/tests/hashtable-test |grep hashtable-test.c
 ../../../src/lib/tests/hashtable-test.c

 I might be able to fix it even better, by overriding __FILE__ myself(with -D)
 on the cmdline, instead of letting it be filled in by cpp from -c.

Btw, for those who want to fix this in their own source, when making the build
directory, and then calling configure, use a relative path to the location of
configure.  The relative path will then be used in the encoding of $srcdir,
and standard rules should be able to cope with it.

imformation leakage in debian binaries

2003-08-23 Thread Joey Hess 
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
#