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