Version(s): 1.0.2 and prior versions Description: A file permission vulnerability was reported in bzip2. A local user can change the permissions of certain files on the target system. A local user with write access to a directory that the target user is using bzip2 with to extract or compress a file can change the permissions on any file owned by the target user. When extracting a file, the software applies the permissions of a compressed file to the uncompressed file. However, there is a time period between when the file handle for the uncompressed file is closed and the permissions are changed. A local user can exploit this race condition by replacing the decompressed file with a hardlink to another file on the target system during that time period. The hardlinked file's permissions will be changed to the permissions of the compressed bzip2 file. Impact: A local user can cause the permissions on files owned by the target user to be changed when the target user decompresses a file using bzip2. Solution: No vendor solution was available at the time of this entry. As a workaround, the author of the report indicates that you can make sure that any directory that is being used by bzip2 to compress/decompress files is only writeable by the user or you can set the sticky bit on the directory's permissions.
This is not really severe, since it requires unpacking into a world-writeable, non-sticky-set directory, and knowing in advance which file will be unpacked with which permissions... not sure we should accept it. That said, "the re-application of the permissions to the extracted file could be done in a more secure fashion, namely by calling fchmod on the extracted file's descriptor instead of calling chmod on the path to the file."
i dont mind fixing a minor bug like this but as you say, it doesnt seem worthy of a GLSA at this point ... also, upstream seems kind of dead with this package ... we've tried to contact them before about bugfixes and never had a response :( last release -> Jan 2002
gzip is affected by the same bug. That said, like Tavis said, chown is vulnerable to the same race condition, since the file can be switched with a hardlink by the time you run the command. I propose to resolve as WONTFIX.
I vote WONTFIX as well.
I agree, WONTFIX.
Reopen if you disagree, we'll flame you and close it again :)
*** Bug 92927 has been marked as a duplicate of this bug. ***
