The 'Security Digest' Archives (TM)

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

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #38 1989-10-28 (1 file, 8048 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Sat, 28 Oct 89 19:03:24 PDT
Subject: Security Digest V1 #38

Security Digest Volume 1 Issue 38


            Hole in Elm Mailer
            Re: SunOS 3.5 /etc/exports
            Re: rcp security problem with nobody (PC-NFS)
            Re: rcp security problem with nobody
            Summary of SunOS 4.X security hole
            Re: Summary of SunOS 4.X security hole
            Re: Summary of SunOS 4.X security hole
            Does anyone have a tool which traps commands executed through su?
            Re:  Does anyone have a tool which traps commands executed through su?
            Re:  Does anyone have a tool which traps commands executed through su?


Date: Sun, 22 Oct 89 11:32:26 CDT
From: Greg Hackney <uunet!!root>
Subject: Hole in Elm Mailer

Edwin Kremer ([email protected]) has discovered a hole
in the 'Elm' mail program, and reported it to the Elm developers.

If you set your $MAIL variable to someone else's mailbox,
and invoke Elm, their mailbox is readable.

Attached is his suggested temporary workaround (although I
haven't tried it).
Greg        Internet: [email protected]         Southwestern Bell
Hackney     UUCP: {rutgers,bellcore}!texbell!hack   Telephone Company

----<cut here>------
*** init.c.ORIG Sat Oct 21 21:15:29 1989
--- init.c      Sat Oct 21 21:18:29 1989
*** 269,276 ****

!       /* check for permissions only if not default mail file */
!       if(strcmp(requestedmfile, defaultfile) != 0) {
          if ((errno = can_access(requestedmfile, READ_ACCESS))) {
            dprint(1, (debugfile,
                  "Error: given file %s as folder - unreadable (%s)!\n",
--- 269,279 ----

!       /*
!        * ALWAYS check for permissions on the mail file, even if
!        * it's the default mailbox because users may fake another
!        * default mailbox by setting their environment variable MAIL.
!        */
          if ((errno = can_access(requestedmfile, READ_ACCESS))) {
            dprint(1, (debugfile,
                  "Error: given file %s as folder - unreadable (%s)!\n",
*** 280,286 ****
-       }

        /** check to see if the user has defined a LINES or COLUMNS
            value different to that in the termcap entry (for
--- 283,288 ----


Date: Mon, 23 Oct 89 10:28:19 EDT
From: uunet!!bet (Bennett Todd)
Subject: Re: SunOS 3.5 /etc/exports

Thanks for the tip about the netgroups; I figured that was some such Sun
sleaze. We continue to be pleased with the lack of YP (as well as SunOS

Someone locally suggested that (a) working fine once the critters are up
multiuser, plus (b) not working in single-user to mount the server's
root, probably means that the hostname assignment was hosed. I looked
more closely at that and sure enough, the /etc/rc.boot I was working
from (provided by your friend and mine, Sun Microsystems) had the
invocation of /bin/hostname *after* the attempt to mount (via NFS) /pub.
So much for NFS mounting protection. So, I moved the line to right after
the big block if that handles /etc/passwd repairs, right before the line
to zero out mtab. I also made /bin/hostname a real copy of the
executable and not a symlink (these roots are *still* well under 2M
total) and all seems to be working fine again.

Thanks for the support, and allow me to encourage all of you, if you
haven't already done so, to add the list of hosts you want to permit to
each line in /etc/exports (or, if you are putting up with YP, to make a
suitable netgroup) and restrict who can mount your filesystems. This is
one of those steps that is easy to postpone, since all it does is
introduce a gargantuan security hole. Somehow it can seem hard to work
up the enthusiasm to keep hacking after you get things basically
working, but this one isn't too bad.


Date: Sat, 21 Oct 89 13:22:41 +0100
From: uunet!!cgch!wwtz (Wolfgang Wetz)
Subject: Re: rcp security problem with nobody (PC-NFS)

in "Security Digest Volume 1 Issue 37" the contribution
from [email protected] (Wietse Venema) on PC-NFS problems
with user 'nobody' was saying, that rcp commands under nobody are
executed with root privileges.

The message was indicating:

> Repeat-by:
>     On a pc with PC/NFS, execute the following commands:
>       net name nobody
>       rcp hostname:/etc/uucp/L.sys .

I did check this and found, that under SunOS 4.0.3 with PC-NFS
Release 3.0 this is *not true*. I also checked this against our (last)
machine running SunOS 3.5; I could *not* reproduce the described
behaviour either.


Date: Tue, 24 Oct 89 18:59:23 PDT
From: uunet!allegra!mp
Subject: Re: rcp security problem with nobody

As far as I can tell, here are the problems with rcp under SunOS 4.0.

( terminology notes: uid means effective userid;
  getuid() returns the real userid.  I didn't make up the names! )

- there are some security problems inherent to the 4.[23] Berkeley versions
of rcp.  Berkeley published fixes for these in comp.bugs.4bsd.ucb-fixes
in May.  It looks like [at least some of] these fixes were made in the
uunet version, based on the ascii strings that version contains.

- the setreuid() system call takes (signed) ints (32 bits on current
Sun-[234] systems) as arguments, but was changed in SunOS 4.0 to reject
any arguments that have any of the upper 16 bits turned on, to ensure
that only "short" values get passed in.  So, some setreuid() calls
will fail with EINVAL.  Also, the kernel keeps the uid
and ruid as (signed) short ints, so some comparisons between these and
setreuid()'s int arguments will fail if the short ints are negative, so
some setreuid() calls that ought to work won't (you'll get an EPERM
error, presumably from suser()).

The result is that some setuid(), seteuid(), and setruid() calls that
rcp makes may fail when they're called with negative signed ints, or
when the process is running with effective userid < 0, leaving the
program running with uid or euid 0.  The bugs affect both client-side
and server-side rcp's, though at least one client-side bug was fixed in
the ucb-fixes version and thus on the uunet version.

My fix to rcp was to cast the args to setuid(), seteuid(),
and setruid() to be uid_t, and to check for failure of those

Unfortunately, this winds up making rcp not work at all for
userid -2, because the setuid(userid) calls will
fail when the effective userid is -2.  Also, much as I was
tempted to just change the types of the "userid" and "myuid" variables
to uid_t, this means that pwd = getpwuid(userid = getuid())
will fail for userid -2.
There's probably a way to program around these misfeatures,
but I've yet to see someone who NEEDS to su to nobody and run
programs like rcp.

While Sun could do us all a big favor and rationalize their userid and
groupid datatypes, we should all start to look closely at BSD and
Sun programs that run as root and check for obvious security holes such
as system calls not being checked for failure, buffers being overrun,
exec's of other, less secure programs, etc.


Date: Wed, 25 Oct 89 10:05:27 EDT
From: uunet!umiacs.UMD.EDU!steve
Subject: Summary of SunOS 4.X security hole

   This is a summary of a security hole (discovered, so far as I know, by
Wietse Venema, [email protected]) that exists in SunOS 4.X, and
potentially in many BSD-derived systems.

   The hole depends on a number of other things being not quite right.
First, the victim machine has to have a uid in /etc/passwd whose value is
negative.  Since Sun and DEC (and, in fact, most vendors who support NFS)
both ship machines with a 'nobody' (uid -2) entry, this is a common

   Second, the victim system must have converted from treating uids as ints or
shorts to treating them as uid_t (unsigned short, as defined in sys/types.h).
The conversion must also have been done in a somewhat bizarre manner, in
the sense that a setuid(-2) will fail, while a setuid((uid_t)-2) will not
fail.  Out of the systems I've tried (including Suns running SunOS 3.2 and
4.0.1, mostly-4.3-tahoe VAXen, Ultrix 3.1 DECstations, and Encore Multimaxes
running beta-test software) only Suns running 4.X have this problem.

   Third, the victim system must have a rcp program which doesn't cast uids
to uid_t inside of setuid() calls, or which doesn't otherwise treat them
consistently as uid_t.  It looks like the sources for rcp on all the
machines I could check (except what's on pre-alpha 4.4BSD machines) violate
one or the other of these restrictions.  As an aside, it appears that the
kernel sources to the setreuid() call (which is all setuid() calls on a
BSD-derived system) will accept ints on 4.3-tahoe, pre-4.4BSD, Ultrix 3.1,
and SunOS 3.2 systems.  I suspect that SunOS 4.X declares the parameters to
the kernel setreuid() routine as of type uid_t, but I can't check that,
since I don't have 4.X sources yet.

   Fourth, the home directory for an account with a negative uid must have a
.rhosts file in it.  In the Sun-distributed passwd file, the home directory
for the 'nobody' account is /, so in this case, the victim machine is
vulnerable to any user who can run as 'nobody' on any machine listed in
/.rhosts.  Some sites run with ~nobody set to some other place, and with
machines (such as PCs) listed in ~nobody/.rhosts; as such, these sites are
particularly vulnerable to having someone on a PC listed in ~nobody/.rhosts
do something like:

        net name nobody
        rcp victim:/etc/uucp/L.sys .

or, even worse:

        net name nobody
        rcp passwd.cracker victim:/etc/passwd

   The problem here is that rcp invokes rshd on the victim system, which
actually becomes uid -2 without problems.  However, rshd then runs rcp on
the victim to manage the transfer.  Rcp is setuid root; it runs as root,
then tries to go back to being 'nobody'... but the setuid fails, and the
process is left running as root.

   To repeat the problem without a PC handy, use the following steps.  Note
that this only demonstrates the problem; a successful attack by these steps
would be silly, since the cracker would already have root access.

        1) Put a machine name (i.e., into ~nobody/.rhosts
                on the victim machine.

        2) On the cracker machine, su, then su nobody.

        3) On the cracker machine, do:

                rcp victim:/etc/uucp/L.sys /tmp/L.sys

        You'll end up with a copy of L.sys, which you shouldn't have been
        able to read as nobody.

   Enclosed is a fix from C.  Philip Wood, which closes the hole.  An
alternative fix would (probably; untested) involve treating uids as uid_t
consistently throughout rcp.c.  (Most versions of rcp.c that I've seen could
*desperately* use some delinting.)  For sites without sources, either making
the uid on nobody be positive, or making the home directory for 'nobody'
someplace that doesn't exist, should close the hole.  Again, while only
SunOS 4.X sites seem to be affected, other vendors might be well-advised to
clean up their rcp sources, and to clean up the handling of uids in general
for all programs and man entries.  (SunOS 4.0.1, at least, doesn't seem to
mention the use of uid_t in the setreuid(1) man entry, and in other related
man entries.)

   This summary describes what I think is going on, to the best of my
knowledge.  Vendors and administrators are advised to think about the
discussion here, and to check my thinking to be sure that I'm not somehow
giving bogus advice.  At many sites, this will not be a major problem.
However, since the problem does seem to exist, I and others feel that people
should be made aware of it.

   Have fun.  Thanks to Wietse, Philip Wood, and the many others who helped
in tracking down all the fine details.

This fix is for SunOS 4.0.3, but others will be very similar.

~~Date: Mon, 23 Oct 89 15:54:39 MDT
~~From: cpw%[email protected] (C. Philip Wood)
~~Message-Id: <[email protected]>
~~To: [email protected]
~~Subject: Re: Forwarded mail about the nobody/rshd security hole

This should be my last froth at the mouth.  The bug is in rcp.c and
the fix is what you guessed.  I just tried the fix out and things are

------- rcp.c -------
*** /tmp/da7746 Mon Oct 23 15:51:53 1989
--- rcp.c       Mon Oct 23 15:48:29 1989
*** 111,115 ****
                        iamremote = 1;
                        (void) response();
!                       (void) setuid(userid);
                        source(--argc, ++argv);
--- 111,115 ----
                        iamremote = 1;
                        (void) response();
!                       (void) setuid((uid_t)userid);
                        source(--argc, ++argv);
*** 117,121 ****
                    case 't':           /* "to" */
                        iamremote = 1;
!                       (void) setuid(userid);
                        sink(--argc, ++argv);
--- 117,121 ----
                    case 't':           /* "to" */
                        iamremote = 1;
!                       (void) setuid((uid_t)userid);
                        sink(--argc, ++argv);


Date: Thu, 26 Oct 89 9:51:14 EDT
From: uunet!!chip (Chip Salzenberg)
Subject: Re: Summary of SunOS 4.X security hole

In a recent message, [email protected] explains plainly the SunOS 4.X
"nobody" bug.  He also includes a fix for rcp, written by C. Philip Wood.
The given fix seems to work; but I am appalled that

        (void) setuid((uid_t)userid);

is actually considered better than

        (void) setuid(userid);

from a security point of view.  Does no one check return values of system
calls?  What if, through some error, rcp were run without root privileges,
so that setuid() failed with EPERM?  Or what if it were run under other,
subtly unexpected, conditions that might cause the setuid() to fail?

Note well:  If the return value of setuid() had been checked, and if its
failure had aborted the rcp in progress, the confusion over uid_t would
not have caused a security hole.

The "nobody" security hole resulted from two bugs.  The definition of uid_t
was one of them; it is fixed by the published patch.  The other bug is rcp's
abysmal error checking; it remains a potential disaster.


Date: Thu, 26 Oct 89 13:39:11 EDT
From: uunet!telxon!teleng!gorpong (Gordon C. Galligher)
Subject: Re: Summary of SunOS 4.X security hole

Not that it really will make a difference, but I currently had a problem open
with SUN on the kernel folks, and I remarked about this very problem.  He
didn't have any idea about it and when he checked the code for 4.1pb (Pre-
release Beta version) it was still there!  I have since sent him Steve
Miller's and Chip Salzenberg's mail directly to him, and suggested that
he have the engineers take a serious look at things like this before they
actually go with the Beta version to various sites.

No, I don't have rose-colored glasses on, but I do hope that this person
can make some sort of difference and have SUN wake up and possibly fix
some of these rather obvious problems in the code.

I would like to apologize to Steve and Chip for just forwarding their mail
to SUN without asking there permission, but Rob wanted the mail, and since
SUN software support hasn't been the greatest, I thought it would be
advantageous to send the information as soon as possible, before he changed
his mind!

[ I was considering starting a Sun-only security list so that non-Sun-users
  could cut the volume of material to read by half - 1/2 8-) - neil ]


Date: Thu, 26 Oct 89 21:26:24 EDT
From: CERT Advisory <uunet!!cert>
Subject: CERT_RCP_Advisory

                            CERT Advisory

                           October 26, 1989

                        Sun RCP vulnerability

A problem has been discovered in the SunOS 4.0.x rcp.  If exploited,
this problem can allow users of other trusted machines to execute
root-privilege commands on a Sun via rcp.

This affects only SunOS 4.0.x systems; 3.5 systems are not affected.

A Sun running 4.0.x rcp can be exploited by any other trusted host
listed in /etc/hosts.equiv or /.rhosts.  Note that the other machine
exploiting this hole does not have to be running Unix; this
vulnerability can be exploited by a PC running PC/NFS, for example.

This bug will be fixed by Sun in version 4.1 (Sun Bug number 1017314),
but for now the following workaround is suggested by Sun:

Change the 'nobody' /etc/passwd file entry from



nobody:*:32767:32767:Mismatched NFS ID's:/nonexistant:/nosuchshell

If you need further information about this problem, please contact
CERT by electronic mail or phone.


Date: Thu, 26 Oct 89 14:09:02 EDT
From: ccicpg!cci632!rochester!ll-xn!kathy (Kathryn Smith)
Subject: Does anyone have a tool which traps commands executed through su?

For complex political reasons the set of systems which I administrate has
a group of about 6 people who have the root passwords for various systems.
Now, while I trust these people's intentions and within reason their
knowledge of the system, none of us are perfect.  I would find it very
useful if there were some way I could trap and keep a record of all the
commands executed when someone has su-ed to root, just from the point of
view of not having to run around and ask half a dozen people to find out
who did something strange, and why.

Surely I'm not the first system administrator who has wanted to do something
like this.  I would appreciate pointers to any tools which would enable
me to do this, public domain or otherwise.  We are currently running a Vax
under 4.3 BSD, assorted Sun 3 systems under SunOS 3.5 and SunOS 4.0, and
a couple of Concurrent systems running their version of Unix.

[ How about something like:
Remove "secure" from every line in /etc/ttytab so that they have to su,
force them to have su aliased to "su -" or put in a buffer script to do
it for them, put "script -a /etc/rootactions" in the /.login file,
make sure /etc/rootactions is mode 700 so non-roots can't read it - neil ]


Date: Fri, 27 Oct 89 06:06:14 PDT
From: [email protected] (David H. Wolfskill)
Subject: Re:  Does anyone have a tool which traps commands executed through su?

Might it be a step in the right direction to provide each of them with a
unique login (for which the uids would all still be 0); thus each could
have a unique login/password pair -- thus helping (somewhat) to
establish individual accountability?

Granted, someone in such a position who had malicious intent could do
some pretty ugly things -- but not (much) worse than could be done now.

Granted, it's crude, but it's cheap, and (I think) may be helpful.


Date: Fri, 27 Oct 89 15:55:52 EDT
From: uunet!telxon!teleng!gorpong (Gordon C. Galligher)
Subject: Re:  Does anyone have a tool which traps commands executed through su?

#Might it be a step in the right direction to provide each of them with a
#unique login (for which the uids would all still be 0); thus each could
#have a unique login/password pair -- thus helping (somewhat) to
#establish individual accountability?

This would not stop them from su'ing to that special account, or if they
will be logging in as that special user, then you have to make sure their
terminal is considered 'secure' in the /etc/ttytab (or /etc/ttys, etc.).
If you are dealing with terminal servers and pseudo-terminals, then you have
to make sure all of your pseudo-terminals in the /etc/ttytab file are
considered 'secure'.  I surely wouldn't want to leave my system wide open
like this.


        End of Security Digest Volume 1 Issue 38