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. http://www.securityfocus.com/archive/1/394965
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) released. Ivana Varekova
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. http://rhn.redhat.com/errata/RHSA-2005-357.html
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 derek.edu. 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.