Sun Security Hole

[Seth Robertson]

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)