Security Vulnerabilities in the gzip(1) Command

---

Impact

Security vulnerabilities in the gzip(1) command may result in one or both of the following issues:

1. An unprivileged local user may be able to change the permissions on another user's file if the targeted user is uncompressing a file in a directory which is writable by both users.

This issue is referenced in the following document:

• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0988

2. An unprivileged local user may be able to create arbitrary files on the system if they can induce another user to decompress a specially crafted gzip-compressed file using either the "-N" or "--name" options to gzip(1) or gunzip (see gzip(1)). The new files would only be created in directories which the user running gzip(1) has permission to write to.

This issue is referenced in the following document:

• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1228

 

Contributing Factors

These issues can occur in the following releases:

SPARC Platform

• Solaris 8 without patch 112668-03
• Solaris 9 without patch 116340-04
• Solaris 10 without patch 120719-01

x86 Platform

• Solaris 8 without patch 112669-03
• Solaris 9 without patch 116341-04
• Solaris 10 without patch 120720-01

Note: Solaris 7 does not contain the gzip(1) utility and is not affected by this issue.

In order for the first issue described above to occur, the gzip(1) utility must be used to uncompress a file in a directory which is writable by other users and does not have the sticky bit set.

To determine if the sticky bit is set on a directory, the following command can be used:

    $ ls -ld directory
    drwxr-xr-t   2 user group   512 Jul  7 16:38 directory/

If the "t" flag is indicated, as shown above, then the sticky bit is set.

In order for the second issue described above to occur, the gzip(1) or gunzip (see gzip(1)) utility must be invoked with the "-N" or "--name" flag during decompression.

Symptoms

If the first issue described above occurs, the output file created by the gzip(1) command will be a link to another file belonging to the user, rather than the expected file. The target file to which the new output file is linked will have its permissions changed to that of the original file being uncompressed.

For example, if this issue occurred while a file with the following permissions:

    $ ls -l testfile.txt.gz
    -rw-r--r--   1 localu nobody   42 Jul 11 16:53 testfile.txt.gz

was being uncompressed using the following command:

    $ gzip -d testfile.txt.gz

the output file, "testfile.txt" will be either a hard or a soft link instead of the expected output file. A hard link can be identified by using the "ls -l" command as shown below:

    $ ls -l testfile.txt
    -rw-r--r--   2 localu   nobody   11 Jul 11 16:53 testfile.txt

If the file has a link count greater than 1, as in the output above (where the link count is 2), then the file is a hard link. The destination of a hard link can be found by locating other entries in the filesystem which have the same inode number, as in the example commands below:

    $ ls -i testfile.txt
    192922 testfile.txt
    $ find /var/tmp -inum 192922
    /var/tmp/shared-dir/cantread.txt
    /var/tmp/shared-dir/testfile.txt

A soft link can be identified using the "file -h" command. If the file is a soft link, the output will be similar to the following:

    $ file -h testfile.txt
    testfile.txt:  symbolic link to /var/tmp/shared-dir/cantread.txt

If this issue occurrs, the destination of the hard or soft link will have had its permissions changed to those of the original gzip-compressed file:

    $ ls -l /var/tmp/shared-dir/cantread.txt
    -rw-r--r--  2 localu  nobody  11 Jul 11 16:53 /var/tmp/shared-dir/cantread.txt

If the second issue described above occurs, the expected output file will not exist, and a new file will have been created on the system. If the the "-v" flag was passed to the gzip(1) utility while the compressed file was being decompressed, gzip(1) will have reported the names of any files created (the default behavior of gzip(1) is to delete the original file following decompression, so this cannot be done retrospectively).

For example, if a compromised file was decompressed using the following command (in this case the '-v' flag is used, which highlights the file creation):

    $ gzip -vdN testfile.txt.gz
    testfile.txt.gz:  -22.2% -- replaced with /tmp/testfile.txt

the expected output file 'testfile.txt' will not exist:

    $ ls testfile.txt
    testfile.txt: No such file or directory

and the new file "/tmp/testfile.txt" will have been created and will have contents determined by the author of the original compressed file:

    $ ls /tmp/testfile.txt
    /tmp/testfile.txt

 

Workaround

The first issue described above can be avoided by setting the sticky bit on any shared directories in which the gzip(1) utility will be used. To set the sticky bit on a shared directory, use a command similar to the following:

    $ chmod +t shared_dir

The permissions of a compromised file will be set to those of the archive being uncompressed, and therefore reducing the permissions of any gzip(1) archive before uncompressing it will prevent another user from gaining access to other files.

For example, the following command could be run on a gzip(1) archive before uncompressing it, to ensure that only the owner of the file can read it:

    $ chmod 600 archive.gz

The second issue described above can be avoided by not using the "-N" or "--name" flags when decompressing files with gzip(1) or gunzip.

 

Resolution

This issue is addressed in the following releases:

SPARC Platform

• Solaris 8 with patch 112668-03 or later
• Solaris 9 with patch 116340-04 or later
• Solaris 10 with patch 120719-01 or later

x86 Platform

• Solaris 8 with patch 112669-03 or later
• Solaris 9 with patch 116341-04 or later
• Solaris 10 with patch 120720-01 or later

Modification History


Date: 26-SEP-2005

• Updated Contributing Factors and Resolution sections

Date: 27-SEP-2005

• Updated Relief/Workaround section

Date: 04-OCT-2005

• Updated Relief/Workaround section

Date: 13-OCT-2005

• Updated Contributing Factors, Relief/Workaround, and Resolution sections

Date: 27-OCT-2005

• State: Resolved
• Updated Contributing Factors, Relief/Workaround and Resolution sections

Attachments

This solution has no attachment