[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44.0209282115300.27715-100000@dell1.moose.awe.com>
Date: Sat, 28 Sep 2002 21:19:42 +0100 (BST)
From: Mark J Cox <mjc@...hat.com>
To: xvendor@...ts.openwall.com
cc: Paul Eggert <eggert@...nsun.com>
Subject: Re: Fwd: GNU tar (Re: Allot Netenforcer problems, GNU TAR flaw)
> Paul, -- is there anything more current than tar-1.13.25 (released
> over a year ago)? Perhaps a CVS repository?
Yes we noticed this problem with ./../ not being caught and told the tar
folks. We allocated CAN-2002-0399 for this, wrote a patch, prepared an
errata, but waited to see if an official fix was coming.
Date: Mon, 27 May 2002 11:44:58 +0100 (BST)
From: Mark J Cox <mjc@...hat.com>
To: bug-tar@....org, eggert@...nsun.com
Cc: teg@...hat.com, bbrock@...hat.com
Subject: [SECURITY] bug in contains_dot_dot routine
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
This was fixed by the routine contains_dot_dot in misc.c in tar, which
catches the case where a tar file contains an entry such as "../foo"
However during testing of 1.13.25 we found that we could still trigger
this problem with an entry such as "./../foo" and this is due to a logic
error in misc.c
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)
Cheers, Mark
--
Mark J Cox / Red Hat / OpenSSL / Apache Software Foundation
mjc@...hat.com // T: +44 798 061 3110 // F: +44 870 1319174
[ Part 2, "" Text/PLAIN (Name: "tmp1.patch") 6 lines. ]
[ Unable to print this part. ]
Powered by blists - more mailing lists
Please check out the
xvendor mailing list charter.
