exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

AA-93.09.File.Ownership.Using.tar.utility

AA-93.09.File.Ownership.Using.tar.utility
Posted Sep 23, 1999

AA-93.09.File.Ownership.Using.tar.utility

SHA-256 | 3da527b77d51d78e52edd679266d2d3672b60d30afc555fa5575057cf1921b9d

AA-93.09.File.Ownership.Using.tar.utility

Change Mirror Download
-----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-----
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close