Note: This is an archival copy of Security Sun Alert 200518 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000395.1.
Solaris 9 Operating System
Solaris 10 Operating System
Solaris 8 Operating System
Date of Workaround Release
Date of Resolved Release
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:
These issues can occur in the following releases:
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.
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
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.
This issue is addressed in the following releases:
This solution has no attachment