Sun Security Hole
Seth Robertson
seth at sirius.ctr.columbia.edu
Tue Jun 20 08:31:29 AEST 1989
Version 2.1.c (censored)
We've solved the security hole in SunOS. Here are the fixes that we recommend.
If you wish the complete copy (this has deleted sections), please send mail
**********
from ** root ** asking for it. Send requests to: "seth at ctr.columbia.edu"
**********
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
-------------
<Deleted because it tells too much>
=================
How to duplicate
-----------------
<Deleted because it tells even more!>
====================
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)
Correction:
Must be implemented by Sun
2) <Deleted because it tells too much && we can't fix it anyway>
This needs to be done by someone with source. Possibly Sun.
Correction:
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:
tty:*:4:
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.
Some people have claimed that this does, in fact, not happen.
It works fine on all the Suns that I've seen. This needs
to be investigated. (Report if yours doesn't do it)
Correction:
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.
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.
Correction:
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 <wuthel!brand at lll-crg.llnl.gov>,
Steve Romig <romig at cis.ohio-state.edu>,
and Steven D. Miller <steve at umiacs.umd.edu>
for their continuing assistance in finding solutions to this problem.
---------------
Redistribution
You may distribute this note to anyone.
--------------------
USE AT YOUR OWN RISK
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.
-Seth Robertson
seth at ctr.columbia.edu
Systems Manager
Center for Telecommunications Research
Columbia University
1220 S.W. Mudd
Columbia University
New York, NY 10027
(212) 854-6475
(212) 316-9068 (Fax)
More information about the Comp.sys.sun
mailing list