bug-cpio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-cpio] [PATCH] symlink target sanity check to prevent --no-absol


From: Pavel Raiskup
Subject: Re: [Bug-cpio] [PATCH] symlink target sanity check to prevent --no-absolute-filenames bypass
Date: Thu, 06 Sep 2018 07:12:27 +0200

On Tuesday, July 4, 2017 3:39:54 PM CEST Cedric Buissart wrote:
> Attempt. n°3 : followed the GNU coding standards and added a testsuite case

JFTR, this is related to CVE-2015-1197, right?

> On Thu, Jun 15, 2017 at 9:37 PM, Cedric Buissart <address@hidden>
> wrote:
> 
> > Attempt n.2 :
> > Created a function that walks the whole path. If anything not-directory is
> > found, return an error. If the path is not fully created, we consider that
> > a success and let cpio decides when time has come.
> > Files will be skipped if no-absolute-path is set and error is return.
> >
> > On Wed, Jun 7, 2017 at 10:46 AM, Pavel Raiskup <address@hidden>
> > wrote:
> >
> >> On Wednesday, June 7, 2017 10:07:21 AM CEST Cedric Buissart wrote:
> >> > > In other words and IMO, if we were about to fix this issue - we
> >> should only
> >> > > refuse to extract files through symlinks.
> >> >
> >> > Through any symlinks, or only those created by the archive itself ?
> >>
> >> Remembering the extracted links might be expensive, and with
> >> --no-absolute-filenames we want to stay in CWD anyway - no matter how the
> >> links
> >> in CWD were created.
> >>
> >> > The latter might look less restrictive, but what happens if a local
> >> > attacker is able to create a symlink. Is it something that should be
> >> > considered ?
> >>
> >> Usually user should avoid races manually when running archiver:
> >> https://www.gnu.org/software/tar/manual/html_node/Race-conditions.html
> >
> > based on the above, I did not try to avoid races.
> >
> >>
> >>
> >> Pavel
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Cedric Buissart,
> > Product Security
> >
> 
> 
> 
> 







reply via email to

[Prev in Thread] Current Thread [Next in Thread]