Bugzilla Bug 89946

From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305255

A directory traversal bug exists in multiple versions of gzip. When
compressing a file, gzip saves its original name but not its path inside
the compressed file. When using gunzip's "-N" option, the original name
found inside the compressed file will be used as the name to save the
decompressed file with. "gunzip -N" doesn't check if the original name inside
the compressed file has any "/" characters in it. This makes it possible to
create a malicious compressed file that when decompressed with "gunzip -N"
will create a file at an arbitrary location in the file system, such as
"/etc/nologin" or "/etc/cron.d/evil".

The command "gunzip -N" prints no output during normal operation, so the
user will not get any warning! The command "gunzip -Nv" prints information
about what file it is creating where, but then it may be too late.

The gunzip command always asks before overwriting existing files, so this
bug only allows for creating new files and not overwriting old ones.

This bug has some limited security implications. It allows attackers to create
arbitrary files with arbitrary contents on a system, if they can get a user or
a program with sufficient rights to decompress a .gz file from the attackers
with "gunzip -N".

At least the following gzip versions are affected: 1.2.4, 1.2.4a, 1.3.3,
1.3.4 and 1.3.5.

Furthermore from: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0988

Race condition in gzip 1.2.4, 1.3.3, and earlier when decompressing a gzip allows local users to modify permissions of arbitrary files via a hard link attack on a file while it is being decompressed, whose permissions are changed by gzip after the decompression is complete.

Not sure wether our versions are affected. Security focus only lists <=1.3.3 as affected, but no versions as unaffected.

IMHO, both of these vulnerabilities are questionable, the race condition
requires improperly set permissions and is of little practical use, if anybody
out there really is vulnerable to this and considers it a problem, then they
cannot safely use any shell utility that creates or manipulates files (for the
same reason mentioned on the other bugs opened in response to Imran's reports).

The gunzip --name is a useful feature, I personally have used this in the past.
Is it nescessary to cripple it by not allowing a directory to be specified?

If you use the gunzip --name, you are explitily stating you dont want gunzip to
just use the filename -.gz, you want it to restore the name stored in the
gzipped file. If this is considered a vulnerability, then how is specifying a
directory any worse than setting the name to .profile? 99% of users are going
to gunzip it in their home directory and overwrite their .profile, this is not
a problem though as the user has to explicitly requested it to restore the name
stored in the file.

Removing the ability to save a directory name solves nothing, and cripples the
application. I think we should WONTFIX both of these.

(btw, we are affected)

mmm i think you missed a few things to note ...

if you do this:
# touch /etc/nologin
# gzip /etc/nologin
# mv /etc/nologin.gz someevil.gz
# gunzip -N someevil.gz

you will end up with $PWD/nologin, not with /etc/nologin ... gzip does not store paths in its name

however if you craft a gzipped file whose 'name' is /etc/nologin, when you use -N, the result will create /etc/nologin ... in other words, by adding checks for '/' in the filename, we're not crippling gzip's normal functionality

Vapier: I stand corrected, i consulted RFC1952 and it states "This is the
original name of the file being compressed, with any directory components
removed", so users could have an understandable belief that this wouldnt
happen. 

Created an attachment (id=56955) [edit]
gzip-1.3.5-dir-trav.patch

original patch suggested by Ulf in the debian report caused proper behavior to
misfunction

i wrote a new patch which adds logic inside of the code which parses the name
in the gzip header ... seems to fix the issue for me, please review

tigger, taviso, solar please review patch.

The patch is OK, but considering this a security bug may be overkill : people
uncompressing as root with -N without testing first have no clue anyway...

What's the opinion of the other security guys ?

i wouldnt say that ... if root is in their ~/ then one would expect gzip to
extract to $PWD regardless

I still think you want to send your patch to Ulf Harnhammar the deb guy for
input.
I cant really comment on the patch if it does the right thing or not. spankys 
patches are usually good so it probably can/should work it's way into ~arch

Created an attachment (id=57510) [edit]
gzip.dirtraversal_better.patch

Revised patch by Ulf Harnhammar for the directory traversal vulnerability.

Response from Ulf:

I tested it and looked at it, and it seems to work. You avoid the base_name() and strcpy() calls from my second patch, so it might even be a better solution.

// Ulf

doesnt matter to me which patch goes in as long as they both are documented ...
anyone else care ?

ah well redhat/fedora went with the base_name/strcpy so we might as well to
play along

gzip-1.3.5-r6 now in portage with the fix

Thx SpanKY.

Arches please test and mark stable.

Note that m68k is not CC'ed as they don't have a valid Bugzilla account. Someone(vapier?) please fix that.

stable on amd64

sparc stable.

ppc64 stable

x86 stable

Stable on ppc.

Stable on hppa.

Stable on alpha + ia64.

arm/s390 stable

mips stable.

GLSA 200505-05