Very Computer

1)  I recently decided to use CERT advisories on a regular basis to maintain
security  at my site, and a question immediately arose: advisories are
published via email or news; what prevents any cracker to publish a fake
advisory, giving a recommendation that when applied will in fact weaken
security (e.g. binary patch removing authentication from a server)?

2) I just realized that my SunOS 4.1.3 tar restores file owners that were
used in creating the archive; this allows any user to create whatever
root-owned file he wants in his directories. (suid bits aren't restored,
though!). Is this known as a security problem? It does provides a "chown"
capability to unprivileged users, which I really don't like...

3) When I found the problem, I went to a CERT ftp archive, searched old
advisory titles for the string "tar", and found nothing. I there any
other archive I should consult?

   Thanks in advance!

1) Everybody agreed that faking a CERT advisory on the news or
mailists is easy, so  THIS SHOULD BE IN THE FAQ, shouldn't it?

2) as several people mentioned, the advertised tar ehavior is to
restore file ownership for the superuser only (my /usr/bin/tar
isn't suid, of course). Someting's wrong, however; let's cal
test.tar an archive which contained a file that was root-owned when
the archive was created. Now, the problem only shows up when
extraction takes place in a particular directory, which appears to
NFS-mounted from an HP-HPUX9.05:

speedy$ whoami
john

speedy$ cd

speedy$ /bin/pwd
/auto/theHP9000/hpnet/john

speedy$ ls -l test.tar
-rw-rw-rw-  1 john      10240 Jun 16  1995 test.tar

speedy$ tar xvf test.tar
x hosts, 164 bytes, 1 tape blocks
tar: can't set time on hosts: Not owner

speedy$ ls -l hosts
-rw-r--r--  1 root            0 Jun 16  1995 hosts

Please note that:

- the restored file is empty
- the theHP9000/hpnet filesystem is exported without root permission

My analysis is that the normal way for of action of tar is to
restore the file with its original owner, then to change the owner
to john, which can't be done in this case since speedy doesn't
have root access on the filesystem.

  If this is correct, it means that tar, a non root-suid
program executed by an unprivileged user, relies on root privileges
to do its job... which doesn't fit with what I know of Unix! Unless
the "create file / change owner" sequence is bundled into one
system call?

  Any explanation welcome!

: 1)  I recently decided to use CERT advisories on a regular basis to maintain
: security  at my site, and a question immediately arose: advisories are
: published via email or news; what prevents any cracker to publish a fake
: advisory, giving a recommendation that when applied will in fact weaken
: security (e.g. binary patch removing authentication from a server)?

Nothing I guess.  Let's all be careful :)

: 2) I just realized that my SunOS 4.1.3 tar restores file owners that were
: used in creating the archive; this allows any user to create whatever
: root-owned file he wants in his directories. (suid bits aren't restored,
: though!). Is this known as a security problem? It does provides a "chown"
: capability to unprivileged users, which I really don't like...

Do you have tar setuid?  If so, does it need to be?

: 3) When I found the problem, I went to a CERT ftp archive, searched old
: advisory titles for the string "tar", and found nothing. I there any
: other archive I should consult?

I don't know.

Lex

 MF> 2) as several people mentioned, the advertised tar ehavior is to
 MF> restore file ownership for the superuser only (my /usr/bin/tar
 MF> isn't suid, of course). Someting's wrong, however; let's cal
 MF> test.tar an archive which contained a file that was root-owned when
 MF> the archive was created. Now, the problem only shows up when
 MF> extraction takes place in a particular directory, which appears to
 MF> NFS-mounted from an HP-HPUX9.05:
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Bingo.  Y'see, tar on SunOS *always* tries to set the user and group IDs,
but normally can't, because BSD-ish filesystem semantics won't let you
"give away" a file (originially for quota reasons, IIRC).

SysV-ish filesystem semantics *will*.

See the note about _POSIX_CHOWN_RESTRICTED in the chown(2v) man page on
the Sun; I bet the HP-UX filesystem does *not* stop you from chowning
files away from yourself.

Weird interactions like this are fun, aren't they?
--

     512/03829F89 =  D7 C9 A7 80 8C 84 3F B2  27 E1 48 61 BF FC 18 B4
    1024/66CB73DD =  46 8E FD F5 12 8E 13 4C  2C 8A 92 A3 B0 D5 2A 5E
          [ Public keys available by finger, WWW, or keyserver ]

Quote:>2) as several people mentioned, the advertised tar ehavior is to
>restore file ownership for the superuser only (my /usr/bin/tar
>isn't suid, of course). Someting's wrong, however; let's cal
>test.tar an archive which contained a file that was root-owned when
>the archive was created. Now, the problem only shows up when
>extraction takes place in a particular directory, which appears to
>NFS-mounted from an HP-HPUX9.05:
>speedy$ whoami
>john
>speedy$ cd
>speedy$ /bin/pwd
>/auto/theHP9000/hpnet/john
>speedy$ ls -l test.tar
>-rw-rw-rw-  1 john      10240 Jun 16  1995 test.tar
>speedy$ tar xvf test.tar
>x hosts, 164 bytes, 1 tape blocks
>tar: can't set time on hosts: Not owner
>speedy$ ls -l hosts
>-rw-r--r--  1 root            0 Jun 16  1995 hosts
>Please note that:

nuki[rk] > uname -a
SunOS nuki 4.1.3 2 sun4m
nuki[rk] > cd /etc
nuki[rk] > tar -cvf /tmp/test.tar hosts
a hosts 27 blocks
nuki[rk] > cd /tmp
nuki[rk] > tar vtf test.tar
rw-r--r--  0/10  13667 Jun 14 13:10 1995 hosts
nuki[rk] > id
uid=107(rk) gid=50(NetUSE) groups=50(NetUSE),0(wheel)
nuki[rk] > which tar
/bin/tar
nuki[rk] > ls -l /bin/tar
-rwxr-xr-x  1 root       163840 Sep 29  1994 /bin/tar*
nuki[rk] > tar -xvf test.tar
x hosts, 13667 bytes, 27 tape blocks
nuki[rk] > ls -lg hosts
-rw-r--r--  1 rk       NetUSE      13667 Jun 14 13:10 hosts
nuki[rk] > whoami
rk

So it works correct. It is DIFFERENT, when under ROOT uid, because then tar restores
the orginal permissions

Quote:>My analysis is that the normal way for of action of tar is to
>restore the file with its original owner, then to change the owner
>to john, which can't be done in this case since speedy doesn't
>have root access on the filesystem.

Roland

--
Roland Kaltefleiter | OFFICE: n/a please use Papermail

In another world in another time to come, there won't be MS-DOS.

[...]

Quote:>> 1)  I recently decided to use CERT advisories on a regular basis to maintain
>> security  at my site, and a question immediately arose: advisories are
>> published via email or news; what prevents any cracker to publish a fake
>> advisory, giving a recommendation that when applied will in fact weaken
>> security (e.g. binary patch removing authentication from a server)?

For instance, "CA-95:07a.REVISED.satan.vul" comes with
"CA-95:07a.REVISED.satan.vul.asc".

[...]

                                                Olivier L'Heureux

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

Laboratoire de microlectronique de l'Universit catholique de Louvain

<http://www.dice.ucl.ac.be/~lheureux>                     Belgium                  
MIME/PGP accepted

I don't know why CERT don't sign the postings they make, but it's better
than nothing..

Chris

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBL+rvLVJ7nmUlvnM9AQE2qAP9FXBT0TgXPryIn2iWhZGq9x/Ap/l67VBx
3DJtyyv2BjIV3xXu9K3XKILf1IRqZkNIo39XIIl4VTi9Rvcs7N/CY4xwVbYAAf9c
SnfSj8qsnjJFIZn4YDykcOccWC9hvXZ2A4HuGrGf1LBq2SOgVKdR+ToQ/WkON+mZ
+J8XT6VKiwc=
=vMuu
-----END PGP SIGNATURE-----
--

 N-115, Defence Research Agency,  St Andrews Road, Great Malvern, England, UK
 DISCLAIMER: I write only for myself, not for DRA.     Phone: +44 1684 894644