[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Re: CVE-2017-8283 Directory traversal in dpkg-source via indented patches on non-GNU 
From:       Guillem Jover <guillem () debian ! org>
Date:       2017-04-28 1:58:18
Message-ID: 20170428015817.zgsoz5sdjrlou3fm () gaara ! hadrons ! org
[Download RAW message or body]

Hi!

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

This is now CVE-2017-8283.

Thanks,
Guillem
[prev in list] [next in list] [prev in thread] [next in thread]