Security Digest Volume 1 Issue 25 subject(s): 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 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 verbose trace get /etc/passwd /tmp/p quit 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) Correction: 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. 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. 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 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. [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. 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 , Steve Romig , and Steven D. Miller for their continuing assistance in finding solutions to this problem. --------------- Redistribution 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 -------------------- 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. ------------------------------------------------------------------------ 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 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 **********************