[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Sep 2002 11:02:24 +0400
From: Solar Designer <solar@...nwall.com>
To: xvendor@...ts.openwall.com
Cc: Paul Eggert <eggert@...nsun.com>
Subject: Re: Fwd: GNU tar (Re: Allot Netenforcer problems, GNU TAR flaw)
On Sat, Sep 28, 2002 at 09:19:42PM +0100, Mark J Cox wrote:
> Yes we noticed this problem with ./../ not being caught and told the tar
> folks.
I know, -- your message on this is referenced with our fix.
> We allocated CAN-2002-0399 for this,
I'm confused. CAN-2001-1267 or CAN-2002-0399?
I've now added a reference to CAN-2001-1267.
> wrote a patch, prepared an errata, but waited to see if an official
> fix was coming.
Well, with two Bugtraq announcements, I don't think it makes sense to
wait any longer.
Do you also have a CVE number for the symlink issue (see the 1998
Bugtraq posting)?
> We've recently been looking at the vulnerability mentioned on bugtraq
> nearly a year ago:
>
> "Directory traversal vulnerability in GNU tar 1.13.19 and earlier allows
> local users overwrite arbitrary files during archive extraction via a tar
> file whose filenames contain a .. (dot dot)."
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-1267
3APA3A was slightly wrong when saying "and earlier". At least some
earlier versions (1.13.17, 1.13.18) actually had it right.
> I've attached a small patch that fixes this (I didn't spend time looking
> to see if multiple ISSLASH are already stripped, if so you could optimize
> the patch further)
The smaller patch I've provided handles multiple slashes too. It's
more similar to the algorithm which worked in 1.13.18, only strchr()
replaced with the equivalent loop to use ISSLASH().
Also on my list of tar and cpio issues to look into are:
1. Races when creating archives: whether it may be made to leave the
intended directory tree by moving directories around, whether it may
be made to block on reading a FIFO or device, -- should probably use
O_NOFOLLOW, then fstat().
2. Races when extracting archives: whether it will be possible for an
attacker to place [sym]links into directories being extracted such
that files in them would go to the wrong place, -- for example, when
restoring user home directories from a backup, as root. Races between
the calls to chmod() and chown(), -- if chmod() is done first, that
would mean that permissions may be given to the wrong group for a
moment and if chown() is done first it may mean that extra permissions
are given to the file's group for a moment. The right sequence is
chmod() to a safe mode (0700 & mode), then chown(), then chmod().
I expect that all of the races I've mentioned are there. :-(
--
/sd
Powered by blists - more mailing lists
Please check out the
xvendor mailing list charter.
