=============================================================================
SA-93.09      SERT Advisory
         3-Nov-1993
        Warning of file ownerships when using tar
-----------------------------------------------------------------------------

An anomaly was reported to the Security Emergency Response Team that
highlighted a feature of tar(1) which we feel requires a timely reminder to
our constituents and other system managers.

If the files from a tape archive file are extracted while you are running
as root, then tar will create the resulting files with the same user and
group identities, and permissions as they originally had when the tar file
was created.  The tar(1) man page states:
"The owner, modification time, and mode are restored (if possible)."

For example:

Using a normal user account user1 which is in group1:
host> tar xvf tmp.tar
x tmp/a, 8 bytes, 1 tape blocks
x tmp/b, 8 bytes, 1 tape blocks
x tmp/c, 8 bytes, 1 tape blocks
x tmp/d, 8 bytes, 1 tape blocks
x tmp/e, 8 bytes, 1 tape blocks
host> ls -lg tmp
total 5
-rw-------  1 user1  group1    8 Nov  3 09:23 a
-rwx------  1 user1  group1    8 Nov  3 09:23 b
-rw-------  1 user1  group1    8 Nov  3 09:23 c
-rwx------  1 user1  group1    8 Nov  3 09:23 d
-rwx------  1 user1  group1    8 Nov  3 09:23 e
host>

Using root:
host# tar xvf tmp.tar
x tmp/a, 8 bytes, 1 tape blocks
x tmp/b, 8 bytes, 1 tape blocks
x tmp/c, 8 bytes, 1 tape blocks
x tmp/d, 8 bytes, 1 tape blocks
x tmp/e, 8 bytes, 1 tape blocks
host# ls -lg tmp
total 5
-rw-rw----  1 root  daemon    8 Nov  3 09:23 a
-rwxrwx---  1 user1  group1    8 Nov  3 09:23 b
-rw-r-----  1 user2  group1    8 Nov  3 09:23 c
-rwxrwx---  1 user3  group3    8 Nov  3 09:23 d
-rwxrwx---  1 user4  group4    8 Nov  3 09:23 e
host#

This behaviour has been confirmed on the following platforms:
SunOS 4.1.3 (Sun)
Solaris V2.2 (Sun)
Ultrix V4.2A (DEC)
Ultrix V4.3 (DEC)
OSF/1 V1.3 (DEC)
IRIX 4.0.5 (SGI)
* NEWS-OS 4.1R (Sony)

* = this system also exhibited unusual behaviour when the files were
extracted as a normal user by setting the group identity to daemon for all
files, even though the user was not a member of group daemon.

The behaviour does not appear to occur on the following platforms:
UNICOS 7.0.5.1 gar.6 CRAY Y-MP

It is therefore important that after extracting files you check the file
permissions and the user and group identities to determine that they are
appropriate to your needs.  It may not be immediately obvious that the
files have an inappropriate user and group identities, as root will still
be able to access them.

The implications of this are that a user who is a member of the resultant
file's group or possesses the same user identity as the original identity
of the files may have read and write access to those files [depending on
the value set with umask(1)].  This may allow them to modify those files,
changing data or source code prior to you installing a program onto the
system, execute programs that would normally be protected against them, or
replace those programs with versions of their own.

(In the second example above, any user in group1 may read, write, or
execute file "a" via the group permissions, and a user with the same user
identity as user2 may read, write, or execute file "b" as the file's
owner).

As root, the file ownerships may be changed by using the chown(8) command.
Some possible examples (using SunOS 4.1.3) are:
host# /usr/etc/chown root.daemon *
host# /usr/etc/chown -R root.daemon directory-name
host# /usr/bin/find directory-name -exec /usr/etc/chown root.daemon {} \;

The file permissions may also require changing (as root, or as a normal
user).  Some possible examples (using SunOS 4.1.3) are:
host# /bin/chmod 600 *
host# /bin/chmod -R 600 directory-name
host# /usr/bin/find directory-name -exec /bin/chmod 600 {} \;

SERT recommends that you check the file's permissions and user and group
identities after they have been extracted from any archival facility such
as shar(1l), cpio(1), restore(8), and tar(1).  If they are not appropriate
to your needs then they should be changed immediately.

----------------------------------------------------------------------------
The SERT team wishes to thank Roy Chamberlain and Jack Churchill from
CSIRO, Rob McMillan from Griffith University, and Chris Teakle from The
University of Queensland for their advice and cooperation in this matter.
----------------------------------------------------------------------------

If you believe that your system has been compromised, contact SERT or your
representative in FIRST (Forum of Incident Response and Security Teams).

Internet Email:  sert@sert.edu.au
Facsimile:  (07) 365 4477
SERT Hotline:  (07) 365 4417
    SERT personnel answer during business hours (AEST - GMT+10:00).
    (On call after hours for emergencies).

Security Emergency Response Team
c/- Prentice Centre
The University of Queensland
Qld.  4072.
Australia.