seth@sirius.ctr.columbia.edu (Seth Robertson) (06/20/89)
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@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@lll-crg.llnl.gov>, Steve Romig <romig@cis.ohio-state.edu>, and Steven D. Miller <steve@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@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)