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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ