Red Hat Bugzilla – Bug 155745
CAN-2005-0988 Race condition in gzip
Last modified: 2007-11-30 17:07:17 EST
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.
This issue should also affect RHEL2.1 and RHEL3.
Created attachment 113841 [details]
Proposed patch from Steve Grubb
The new versions (gzip-1.3.3-11.rhel3, gzip-1.3.3-15.rhel4, gzip-1.3-17.rhel2)
This bug has been reported into Debian BTS too. There, a different
patch is suggested to solve the problem. The debian patch is a lot
shorter. Have a look at <URL: http://bugs.debian.org/305255 >.
(Just mentioning it, to give you information about another approach.)
I was just confused. The debian bug I posted is for CAN-2005-1228, and not
this bug. The currect debian bug for CAN-2005-0988 is #303927.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
This has to be re-opened. This patch has produced a bug in gzip files over NFS. The problem crops up
with the fchmod hanging for a long time and pushing rpciod load through the roof. Sometimes the gzip
finishes and sometimes it doesn't. I can produce the file that hangs the machine (1.2gig file,
decompresses into 3gig file) please contact email@example.com.
I have tested this with the Suse unpatched version of this and since it closes the file first then runs chmod
it does not hang indefinitely.