Frank Küster wrote:
Nick Lewycky <nicholas@mxc.ca> wrote:Zoltan Ivanfi wrote:Wouldn't the following simple solution work? --- /usr/bin/dpkg-source 2004-11-11 21:15:52.000000000 +0100 +++ /home/ifi/bin/dpkg-source 2004-12-08 14:45:00.000000000 +0100 @@ -406,7 +406,7 @@ $ENV{'LC_ALL'}= 'C'; $ENV{'LANG'}= 'C'; $ENV{'TZ'}= 'UTC0'; - exec('diff','-u', + exec('diff','-au',[...]It seems to me that this does work. Is there any counter-example?I don't know. What about executables? Buffer overflows? ftp> get http://www.somewhere.net/~possible.sponsee/coolgame* ftp> bye $ dpkg-source coolgame_0.1-1.dsc ######################################### # YOU HAVE BEEN FOOLED ! ######################################## Erase comlete disk (y/Y)? ^C ######################################### # No, don't try Ctrl-C! ######################################## Executing rm -rf /, have fun!
This vulnerability already exists: uuencode it, wait for the build, uudecode and apply. The same as you would for a legitimate binary patch.
Trojaned packages have already been used: mICQ. http://lists.debian.org/debian-devel/2003/02/msg00771.html
But yes, it's a good point. Binary garbage is vastly harder to read than a source diff, and a potential sponsor should check the .diff.gz to see what files it modifies. Especially before running anything as root.
Nick