Category
Security
Release Phase
Resolved
ProductSolaris 9 Operating System
Solaris 10 Operating System
Solaris 8 Operating System
Bug Id
6283819, 6294656
Date of Workaround Release20-JUL-2005
Date of Resolved Release27-OCT-2005
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:
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:
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
References
120719-01
120720-01
112668-03
112669-03
116340-04
116341-04
AttachmentsThis solution has no attachment