oss-security - Directory traversal in dpkg-source via indented patches on non-GNU systems

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170420084105.his3vgnzjpvu4jcv@gaara.hadrons.org>
Date: Thu, 20 Apr 2017 10:41:05 +0200
From: Guillem Jover <guillem@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Directory traversal in dpkg-source via indented patches on non-GNU
 systems

Hi!

Recently, while going through the POSIX standard to check for some
other stuff related to the patch(1) format, I realized that indented
patches are also accepted, which is something the Dpkg::Source::Patch
perl module is not checking, so any of the sanity checks against
directory traveral attacks can be avoided through indenting.

Of course on Debian and other distributions using GNU patch >= 1.7.5,
this is not a concern anymore, as this implementation should be
directory traversal resistant.

But on systems such as the BSDs, with their own patch(1) variant,
this is effective. And while this could (and should in addition be
considered) a problem with those patch implementations, dpkg-source
has always assumed uncooperating underlaying implementations so this
is something it should probably protect against one way or another.

This issue shows up when unpacking a Debian source package for
examination, but then on those non-GNU systems, usage of patch(1)
is unsafe, so I'm not sure how sever this should be considered.

I've got a test case (attached) that fails (the attack is successful) on
at least NetBSD (not tried others), but they share a similar patch(1)
codebase.

And I started adding support for indented patches so thah the checks
would apply, or to just reject them (as a query on codesearch.debian.net)
didn't trigger any instance of such patches in Debian (which would make
them not able to be unpacked if we reject them). But I'm considering the
shorter and more strightforward solution of just requiring GNU patch at
configure time for now. Which is what I'm attaching here as the fix
I'm planning to merge for dpkg 1.18.24.

Given tha above, does this deserve a CVE? At least we have gotten ones
for similar issues in the past.

Thanks,
Guillem

View attachment "0001-Dpkg-Source-Patch-Indented-patch-test-case.patch" of type "text/x-diff" (2559 bytes)

View attachment "0001-build-Detect-the-required-GNU-patch.patch" of type "text/x-diff" (5826 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.