AusCERT - AA-93.09 -- Warning of file ownerships when using tar

HOME
About AusCERT
Membership
PKI Services
Training
Publications
Sec. Bulletins
Conferences
News & Media
Services
Web Log
Site Map
Site Help
Member login
AA-93.09 -- Warning of file ownerships when using tar
Date: 06 February 1997

Click here for printable version
-----BEGIN PGP SIGNED MESSAGE-----

===========================================================================
AA-93.09                        AUSCERT Advisory
		    Warning of file ownerships when using tar
				 3-Nov-1993

Last Revised: 6-Feb-1997 - Added information about GNU tar

- ---------------------------------------------------------------------------

1.  Description

An anomaly was reported to the AUSCERT 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

GNU versions of tar exhibit additional behaviour relating to the username
of the user that owns the files inside the tape archive.  With GNU tar,
the username, in addition to the userid, is stored for each file.  If that
username does not exist on your system, then tar will restore the files
owned by the user running the tar restore command.  The setuid and setgid
permissions on the files are restored intact.  This means that if the tar
restore is performed by the root user, it is possible that a root owned
setuid file may be created.

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 {} ;

AUSCERT 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 AUSCERT 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.
AUSCERT acknowledges Ben Elliston from Comupcat Research for his report
concerning GNU tar.
- ----------------------------------------------------------------------------

The AUSCERT team have made every effort to ensure that the information
contained in this document is accurate.  However, the decision to use the
information described is the responsibility of each user or organisation.
The appropriateness of this document for an organisation or individual
system should be considered before application in conjunction with local
policies and procedures.  AUSCERT takes no responsibility for the
consequences of applying the contents of this document.

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

AUSCERT is located at The University of Queensland within the Prentice
Centre.  AUSCERT is a full member of the Forum of Incident Response and
Security Teams (FIRST).

AUSCERT maintains an anonymous FTP service which is found on:
ftp://ftp.auscert.org.au/pub/.  This archive contains past SERT and AUSCERT
Advisories, and other computer security information.

AUSCERT also maintains a World Wide Web service which is found on:
http://www.auscert.org.au/.

Internet Email: auscert@auscert.org.au
Facsimile:	(07) 3365 4477
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 emergencies.

Postal:
Australian Computer Emergency Response Team
Prentice Centre
Brisbane
Qld.  4072.
AUSTRALIA


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision History

6-Feb-1997	Added paragraph describing GNU tar behaviour.
		Changed SERT to AUSCERT

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key

iQCVAwUBMvny3Ch9+71yA2DNAQFY+wP+Nj7/wGUikROpV2IU1w/1OqtJpKADsWZu
4609RQGcEYHAhH101UzChpl+G6L5VcqdWyNdd/k7ErCKgkolzTgR/U6yu/rpGj3+
/TPIk4buvGltc0SOD7yzHcZhjKBUl+qtDz7/DDOxnl0S+p3kxc9QtJw0Cyj6p6b1
+MTTxgeYzsQ=
=E+bC
-----END PGP SIGNATURE-----