Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 89946

Summary: app-arch/gzip: several issues (CAN-2005-0988, CAN-2005-1228)
Product: Gentoo Security Reporter: Sune Kloppenborg Jeppesen (RETIRED) <jaervosz>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: normal    
Priority: High    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard: A3? [glsa] jaervosz
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 90626    
Description Flags
gzip.dirtraversal_better.patch none

Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-21 10:57:20 UTC

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:

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.
Comment 1 Tavis Ormandy (RETIRED) gentoo-dev 2005-04-21 11:36:18 UTC
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)
Comment 2 SpanKY gentoo-dev 2005-04-21 14:32:29 UTC
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
Comment 3 Tavis Ormandy (RETIRED) gentoo-dev 2005-04-21 15:32:13 UTC
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. 
Comment 4 SpanKY gentoo-dev 2005-04-22 16:22:32 UTC
Created attachment 56955 [details, diff]

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

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
Comment 5 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-23 00:30:50 UTC
tigger, taviso, solar please review patch.
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2005-04-27 05:55:16 UTC
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 ?
Comment 7 SpanKY gentoo-dev 2005-04-27 06:07:00 UTC
i wouldnt say that ... if root is in their ~/ then one would expect gzip to extract to $PWD regardless
Comment 8 solar (RETIRED) gentoo-dev 2005-04-28 09:25:02 UTC
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
Comment 9 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-28 12:19:15 UTC
Created attachment 57510 [details, diff]

Revised patch by Ulf Harnhammar for the directory traversal vulnerability.
Comment 10 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-30 11:07:43 UTC
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
Comment 11 SpanKY gentoo-dev 2005-05-02 11:21:43 UTC
doesnt matter to me which patch goes in as long as they both are documented ... anyone else care ?
Comment 12 SpanKY gentoo-dev 2005-05-02 11:23:10 UTC
ah well redhat/fedora went with the base_name/strcpy so we might as well to play along
Comment 13 SpanKY gentoo-dev 2005-05-02 15:01:03 UTC
gzip-1.3.5-r6 now in portage with the fix
Comment 14 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-02 22:25:53 UTC
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.
Comment 15 Jan Brinkmann (RETIRED) gentoo-dev 2005-05-03 05:45:40 UTC
stable on amd64
Comment 16 Gustavo Zacarias (RETIRED) gentoo-dev 2005-05-03 06:03:00 UTC
sparc stable.
Comment 17 Omkhar Arasaratnam (RETIRED) gentoo-dev 2005-05-03 07:13:18 UTC
ppc64 stable
Comment 18 Olivier Crete (RETIRED) gentoo-dev 2005-05-03 09:55:27 UTC
x86 stable
Comment 19 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-05-03 13:06:34 UTC
Stable on ppc.
Comment 20 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-05-03 14:05:52 UTC
Stable on hppa.
Comment 21 Bryan Ƙstergaard (RETIRED) gentoo-dev 2005-05-04 01:15:41 UTC
Stable on alpha + ia64.
Comment 22 SpanKY gentoo-dev 2005-05-04 15:51:23 UTC
arm/s390 stable
Comment 23 Stephen Bennett (RETIRED) gentoo-dev 2005-05-06 10:55:21 UTC
mips stable.
Comment 24 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-09 12:44:52 UTC
GLSA 200505-05