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 attachment 56955 [details, diff] 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 attachment 57510 [details, diff] 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
