Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 28 Apr 2017 03:58:18 +0200
From: Guillem Jover <>
Subject: Re: CVE-2017-8283 Directory traversal in dpkg-source via indented
 patches on non-GNU systems


On Thu, 2017-04-20 at 10:41:05 +0200, Guillem Jover wrote:
> 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
> 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.

This is now CVE-2017-8283.


Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ