[bug-patch] Directory traversal vulnerability in patch (or dpkg-source) (fwd)

[Christoph Berg]

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.txt

I 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