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 #25 1989-06-27 (1 file, 5515 bytes)
NOTICE: recognises the rights of all third-party works.


Security Digest Volume 1 Issue 25


            Security Hole in SunOS
            CERT Offline
            Security Digest V1 #24
            security hole details
            Re: list(s) ramblings
            Re:  Security Digest V1 #24
            list(s) ramblings
            the list in general


Date: Tue, 27 Jun 89 18:28:53 EDT
From: Seth Robertson <uunet!!seth>
Subject: Security Hole in SunOS

Version:  2.1.1.s  (Security List Version)

There is a large security hole is SunOS.  This hole does exist in
other Unix Operating Systems as well, although we do not have a
complete or necessarily even correct list.  Check out the stuff below
to determine if you are affected.

This hole exists on all versions of SunOS && exists no matter how
you are connected to the world (although Internet people can have
more problems via remote attackers)

The Problem

1)      /etc/utmp is world writable (666 or -rw-rw-rw-) by default in
        SunOS.  Check your system to be sure by typing:
                ls -l /etc/utmp

1.5)    Some versions of tftp do not do a "chroot" and so any user on
        the internet can do a `tftp`, overwrite your /etc/utmp, and
        then use `rwall` to get an account on your system.  This does
        not affect you if you are not on the internet or some similar
        network (but UUCP is safe from this)

                tftp localhost
                mode ascii
                get /etc/passwd /tmp/p

        If you get: "Error code 1: File not found" you are safe from
        remote attacks, but you are still vulnerable to local attacks.

2)      rpc.rwalld looks at /etc/utmp to find out which terminals to
        write to.  That means that if /etc/utmp is wrong (either
        accidently or deliberately), rpc.rwalld will attempt to write
        to name anyway.

3)      inetd runs rpc.rwalld as root (which means that rwalld can
        write on any terminal, or in this case even a protected
        password file.

Fixing the problems

1)      /etc/utmp should not really be world writable.

        The sideaffects of this keep on going.  Thus, we
        do *not* recommend this for SunOS people any more.

        CHANGE IT BACK TO 666.  (And pray)

                Must be implemented by Sun

2)      wall needs to be fixed so that it checks to see that only
        "special" files can be overwritten (e.g. no normal files
        like /etc/passwd)  It should also make sure that the
        string "../" does not appear.

        This needs to be done by someone with source. Possibly Sun.

                None at this time.

3)      rpc.rwalld should not run as root.  It has no need for this
        when having group "tty" privileges will do the same.

        Some people do not have a group "tty"  If you do not, you need
        to make one.  Add an entry to /etc/group that looks like this:

        Either getty or login is supposed to change the ownership of
        a /dev/tty__ group whenever somebody logs in.  At the same
        time it also does a "chgrp" and makes the terminal owned
        by group "tty" with write privileges.

        This is known not to work on many systems, for unknown reasons.
        It usually works on SunOS 4.x and on 3.4, and usually does not
        on SunOS 3.5

                chown 5000.tty /usr/etc/rpc.rwalld
                chmod 6111 /usr/etc/rpc.rwalld

        UID "5000" is, of course, and arbitrary UID.  You should
        make sure that this UID is never used again (by adding
        an entry in the /etc/passwd file with shell /bin/true and
        a password of "*")

        This does both a setuid and a setgid.  The setuid is to make
        sure that the wall does not harm, and the setgid is to make
        sure that the wall can write to all of the terminals it is
        supposed to.

        [SunOS 4.x users:  You can do the following:
                chown bin.tty /usr/etc/rpc.rwalld
                chmod 2111 /usr/etc/rpc.rwalld

        and then change the entry in inetd.conf to:

walld/1   dgram   rpc/udp wait nobody /usr/etc/rpc.rwalld   rpc.rwalld

        which will make rwalld run as nobody.]

4)      in.tftp needs to do a "chroot" call in order to prevent it
        from looking at or overwriting any files.

        SunOS 4.x machines should do the following:
                Edit the /etc/inetd.conf file and replace, if
                needed, "in.tftpd" with "in.tftpd -s /tftpboot"
                Then, the line should look like this:

tftp  dgram  udp  wait  root  /usr/etc/in.tftpd  in.tftpd -s /tftpboot

        SunOS 3.x machines should implement the correction listed.

                There exists a program "/usr/etc/in.tftpbootd" in
                SunOS 3.x which I shall list here:

#! /bin/sh
# @(#)in.tftpbootd 1.1 86/07/08 Copyright (c) 1986 Sun Microsystems, Inc.
# This provides a slightly more "secure" tftp server for
# booting only.  Copy in.tftpd into /tftpboot and ln -s . tftpboot.
exec /usr/etc/chroot /tftpboot /in.tftpd $1

                What you need to do is:

                        cp /usr/etc/in.tftpd /tftpboot
                        chmod 755 /tftpboot/in.tftpd
                        ln -s /tftpboot /tftpboot/tftpboot

                and then edit the /etc/servers file and comment out
                the first "tftp" line and uncomment the second
                "tftp" line (the second line runs in.tftpboot
                instead of in.tftp)

                Thus the lines should look like this:

#tftp    udp     /usr/etc/in.tftpd
tftp   udp     /usr/etc/in.tftpbootd

Thanks to:
        Russell Brand <[email protected]>,
        Steve Romig <[email protected]>,
    and Steven D. Miller <[email protected]>

for their continuing assistance in finding solutions to this problem.


You may distribute this note to anyone who fulfills all of the
following conditions:

1)      Owns/Manages Suns and any other affected machine
2)      Has the Power and Authority to plug the holes
3)      Is Trustworthy


I am trying very hard to make sure everything I tell here is correct,
but I cannot be responsible for anything that happens; including, but
not limited to, people overwriting their own password files and
locking themselves out, people using this information for personal
gain via becoming root or another user on any machine, and my
instructions being outright wrong.

Neither Columbia University nor anything else is responsible for the
information here.  USE THIS AT YOUR OWN RISK.

(But the risk of NOT using it is even greater :-)

All holes should be blocked now.  You should not receive any more
messages from me unless you ask for some :-) or something new
comes up.


Date: Wed, 5 Jul 89 14:30:04 EDT
From: security-request
Subject: CERT Offline

The supply of cold water to our air-conditioners has been turned off due
to a major break in the pipes.  The problem may not be corrected until
the weekend.

The lack of cold water is bad news for the computer room.  All of the
systems are going to be turned off.

For the next day or so,  CERT will not be able to send or receive EMAIL
via the Internet.

We will be in the building if you need to contact us.  Our telephone number
is 412-268-7090.

Please forward this information to others in your group.


Date: Thu Jun 29 14:20:15 1989
From: uunet!ficc!peter
Subject: Security Digest V1 #24

[ The rest of this digest is some of the reponses I received from
my inquiry about mh handling of the list. - neil ]

Speaking as a member of both groups, the Andrew Burt list was no more
difficult to get on... it was just more hassle to enroll and read.


Date: Thu, 29 Jun 89 07:55:16 MST
From: ucsd!gatech!ncar.UCAR.EDU!woods
Subject: security hole details

  I'm all for posting security hole details to this list. I know you make
a pretty good attempt to ensure no crackers get on the list, but even if
there were a few, at least we can be sure that *WE* get the information
the same time as they do, instead of after they crack our systems!


Date: Wed, 28 Jun 89 11:05:30 EDT
From: Chris Torek <uunet!mimsy!chris>
Subject: Re: list(s) ramblings

It has been said that `three men can keep a secret, if two of them
are dead.'  (I saw this quote attributed to Franklin, presumably
Ben Franklin.)  Anyway, we figured out the rwalld/utmp bug given
the description.  For whatever it is worth....


Date: Thu, 29 Jun 89 08:53:44 MDT
From: uunet!cadnetix.COM!root (Operator)
Subject: Re:  Security Digest V1 #24

[ aside to rusty, I decided to go ahead and include this - neil ]

Acutually, Subject: should be:

Subject: list(s) ramblings

Even though I am happy with your handling of the list, I still
"read it through the whole way 8<)", so you can be amazed :-).

It seems to me, given my knowledge of the way security-breakers
work, a lot of them work in groups, sharing their information.
While this may not be true so much of the Unix world, I know that
the most effective crackers at ASU when I was a student were the
ones that shared info among themselves, and I have heard that there
are 'security-cracking' "interest groups" based on bbs's (which I
understand have QUITE strict rules for getting access, but then
they are usually talking about breaking laws, and sharing how-to
info for same, and so they don't want ANY law-enforcement types
getting in...  for obvious reasons, I think.  (The point is, they
have small groups, and that works ok for them))  (Yow, hows THAT
for getting off the point!)

As for your comment about this security mailing list being the best
it can reasonably be, I would say that NOBODY can make a perfectly
secure mailing list.  First of all, lets say that I get a group of
people together that I know.  It seems pretty unlikely that I can
be sure that none of them are secret crackers (that is another method
of finding out 'good' info - have a group of crackers, one of which
is a 'trusted' non-cracker, as far as the outside world knows).  So,
knowing the people involved proves little.  Unfortunately, getting
mail from root does not prove too much, as the other poster mentioned.
Besides, if you have an accomplished cracker, he/she may have already
cracked their system and thus can mail as root.  And, finally, what
makes ANYBODY think that having 'valid' root access proves ANYTHING
about the 'trustworthyness' of that person?  I would maintain that
you lower the probabilities of having a cracker in the midst by
such limitations, but nobody can guarantee that their list does
not contain a cracker somewhere.

Besides, lets assume that you could create a list of people
who were PERFECTLY 'safe'.  Now, you email it out.  If it passes through
a system which has a resident cracker, especially one who has done it
once and can read mail as it passes through, then your 'perfectly
safe' mailing list has a leak.  So, you do the best you can and don't
worry about it too much.  (whatever you do, don't let this note make
you decide that its not worth it.  I just wish that more people
realized that there ain't no such thing as a secure anything. All you
can really do is make getting around the security difficult and hope
that those who want in will decide its not worth the hassle vs. risk.
Thats kindof a negative approach, but lets face it - if someone REALLY
wants in to something, whether its a computer or a building, they will
find a way in, no matter what.)

Well, hows THAT for being a wet blanket? :-)

I guess it comes from my experiences at college)

So, keep up the good work, and don't let some old wet blanket (myself
included!) discourage you.  I think you've done the best you can.
While it is likely that some reading the list are perhaps not quite
as 'pure' as we might like, I think that there 'aint no way to find
them out'.

PS - there is some method of breaking root, which makes 'who' report
your non-root identity (so that someone watching via 'who' would think
that you are NOT root even though you are), and which uses a special
file (in this case, named '...' and which is a 'character-type special
file') to do the magic.  You may already know of this one, but its new
to me.


Date: Fri, 30 Jun 89 03:43 CDT
From: texbell!moray!siswat!buck
Subject: the list in general

I think you are doing a great job.  Please ignore Mr. Burt
and keep up the good work.

Thanks alot!


        End of Security Digest Volume 1 Issue 25