[This bug is caused by essentially the same coding issue as the bzip2
issue (bugtraq id 12954) - the file is extracted and file descriptor
closed before the file is chmod'ed]

================================
gzip TOCTOU file-permissions vulnerability
================================

Software: gzip
Version: 1.2.4, 1.3.3
Software URL: <http://www.gzip.org>
Platform:  Unix, Linux.
Vulnerability type: Time-of-Check-Time-Of-Use
Severity: Low, local user, badly set permissions.

Vulnerable software
====================

gzip 1.2.4 and 1.3.3 and previous versions running on unix.

Vulnerability
==============

If a malicious local user has write access to a directory in which a
target user is using gzip to extract or compress a file to then a
TOCTOU bug can be exploited to change the permission of any file
belonging to that user.

On decompressing gzip copies the permissions from the compressed
gzip file to the uncompressed file. However there is a gap between the
uncompressed file being written (and it's file handler being close)
and the permissions of the file being changed.

During this gap a malicious user can remove the decompressed file and
replace it with a hard-link to another file belonging to the user.
gzip will then change the permissions on the  hard-linked file to be
the same as that of the gzip file.

Fix
====

Ensure that any directory which is being used by gzip to
compress/decompress files is only writeable by the user or
alternatively set the sticky bit on the directory's permissions.