|
From: | Christoph Berg |
Subject: | [bug-patch] Directory traversal vulnerability in patch (or dpkg-source) (fwd) |
Date: | Thu, 30 Dec 2010 16:54:08 +0100 |
User-agent: | Mutt/1.5.21 (2010-09-15) |
Hi Andreas, a fellow Debian developer has concerns that patch allows ".." in path names which would allow an attacker to create arbitrary files using a patch file. In my view, there is no reason to allow that by default, and patch should remove all ".." components in the input, and probably also a leading "/". (Maybe a switch -P, --absolute-names like tar has should then restore the current behavior.) What do you think? Debian would probably issue a security advisory with an updated patch version. We could do the changes ourselves, but would of course prefer an upstream implementation. (Jakub: I'll probably be unavailable for a few days - feel free to NMU and/or coordinate with the release team.) Christoph -- address@hidden | http://www.df7cb.de/
--- Begin Message ---Subject: Directory traversal vulnerability in patch (or dpkg-source) Date: Wed, 29 Dec 2010 20:26:55 +0100 User-agent: Mutt/1.5.21 (2010-09-15) Dear Security Team, I discovered that you can craft a patch that, when applied by "patch",creates/modifies arbitrary files, even outside the current working directory (or its subdirectories). Perhaps this is by design and we are not supposed to ever apply untrusted patches, I'm not sure.One way or another, this bug/feature can be exploited to create a malicious Debian source package in the 3.0 (quilt) format. A proof of concept, which creates /tmp/allyourbase.txt on unpack, is attached:$ ls -l /tmp/allyourbase.txt /bin/ls: cannot access /tmp/allyourbase.txt: No such file or directory $ dpkg-source -x evilpackage_1-1.dsc dpkg-source: warning: extracting unsigned source package (evilpackage_1-1.dsc) dpkg-source: info: extracting evilpackage in evilpackage-1 dpkg-source: info: unpacking evilpackage_1.orig.tar.gz dpkg-source: info: unpacking evilpackage_1-1.debian.tar.gz dpkg-source: info: applying evil.diff Use of uninitialized value $dirname in substitution (s///) at /usr/share/perl5/Dpkg/Source/Patch.pm line 365, <$filehandle> line 2. Use of uninitialized value $dirname in -l at /usr/share/perl5/Dpkg/Source/Patch.pm line 372, <$filehandle> line 2. Use of uninitialized value $dirname in substitution (s///) at /usr/share/perl5/Dpkg/Source/Patch.pm line 376, <$filehandle> line 2. Use of uninitialized value $fn in -e at /usr/share/perl5/Dpkg/Source/Patch.pm line 379, <$filehandle> line 2. Use of uninitialized value $fn in hash element at /usr/share/perl5/Dpkg/Source/Patch.pm line 383, <$filehandle> line 2. Use of uninitialized value $fn in hash element at /usr/share/perl5/Dpkg/Source/Patch.pm line 386, <$filehandle> line 2. $ ls -l /tmp/allyourbase.txt -rw------- 1 jwilk users 32 Dec 29 19:43 /tmp/allyourbase.txtI believe that unpacking untrusted source packages is a common operation amongst sponsors, so this is a serious issue. Both lenny and squeeze and sid are affected.-- Jakub Wilk
evilpackage_1.orig.tar.gz
Description: Binary data
evilpackage_1-1.dsc
Description: Text document
evilpackage_1-1.debian.tar.gz
Description: Binary data
--- End Message ---
signature.asc
Description: Digital signature
[Prev in Thread] | Current Thread | [Next in Thread] |