-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===========================================================================
             AUSCERT External Security Bulletin Redistribution

              ESB-2005.0580 -- Sun Alert Notification 101816
              Security Vulnerabilities in the gzip(1) Command
                               22 July 2005

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:           gzip
Publisher:         Sun Microsystems
Operating System:  Solaris 10
                   Solaris 9
                   Solaris 8
Impact:            Create Arbitrary Files
                   Increased Privileges
Access:            Existing Account
CVE Names:         CAN-2005-1228 CAN-2005-0988

Original Bulletin: 

  http://sunsolve.sun.com/search/printfriendly.do?assetkey=1-26-101816-1

- --------------------------BEGIN INCLUDED TEXT--------------------

Sun(sm) Alert Notification
     * Sun Alert ID: 101816
     * Synopsis: Security Vulnerabilities in the gzip(1) Command
     * Category: Security
     * Product: Solaris 9 Operating System, Solaris 10 Operating System,
       Solaris 8 Operating System
     * BugIDs: 6283819, 6294656
     * Avoidance: Workaround
     * State: Workaround
     * Date Released: 20-Jul-2005
     * Date Closed: 
     * Date Modified: 

1. 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


2. Contributing Factors

   These issues can occur in the following releases:

   SPARC Platform
     * Solaris 8
     * Solaris 9
     * Solaris 10

   x86 Platform
     * Solaris 8
     * Solaris 9
     * Solaris 10

   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.

3. 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 

4. Relief/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.

5. Resolution

   A final resolution is pending completion.

   This Sun Alert notification is being provided to you on an "AS IS"
   basis. This Sun Alert notification may contain information provided by
   third parties. The issues described in this Sun Alert notification may
   or may not impact your system(s). Sun makes no representations,
   warranties, or guarantees as to the information contained herein. ANY
   AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION
   WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
   NON-INFRINGEMENT, ARE HEREBY DISCLAIMED. BY ACCESSING THIS DOCUMENT
   YOU ACKNOWLEDGE THAT SUN SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT,
   INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISE
   OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN.
   This Sun Alert notification contains Sun proprietary and confidential
   information. It is being provided to you pursuant to the provisions of
   your agreement to purchase services from Sun, or, if you do not have
   such an agreement, the Sun.com Terms of Use. This Sun Alert
   notification may only be used for the purposes contemplated by these
   agreements.

   Copyright 2000-2005 Sun Microsystems, Inc., 4150 Network Circle, Santa
   Clara, CA 95054 U.S.A. All rights reserved

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

        http://www.auscert.org.au/render.html?cid=1980

If you believe that your computer system has been compromised or attacked in 
any way, we encourage you to let us know by completing the secure National IT 
Incident Reporting Form at:

        http://www.auscert.org.au/render.html?it=3192

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
===========================================================================

-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQCVAwUBQuA3Yih9+71yA2DNAQKjXAP/b5ZYuBTDpuelmr2DJGctfJ47lvCVt8jX
7xUQjywun10S3vPBSOE9/2FDRugzqtMNCxPPBSTiAsyXa8o19oWUwd5FyYjoaiHx
Dt9Pu/1k2CFngUreoMjUO+5FgZMdkT7Z8M3jlOzjCyctVEgRfMGqx1nEsSqjzVTm
W7Q/EYREDKI=
=02Tm
-----END PGP SIGNATURE-----