Security Digest Volume 1 Issue 32 subject(s): Workstation security Ultrix, r-commands, and the DNS rlogind/rshd broken by nameserver spoofing in in-addr.arpa domains &fix giving-away files Re: giving-away files Re: Ultrix 3.0 mount Re: Two security problems with Ultrix 3.0 Two security problems with Ultrix 3.0 Two security problems with Ultrix 3.0 Re: nameserver security hole hosts.equiv stupidity list ramblings password shadowing ------------------------------------------------------------------------ Date: 05 Sep 89 21:39:33+0200 From: uunet!iis!prl Subject: Workstation security to the moderator, Neil, I'm not sure whether this should be published. [ Every time I put out this digest, I wonder if particularly nasty bugs should be sent out. But I always conclude that it's better to try to inform a select group of system administrators of a problem and risk letting a few bad apples see it, than to try to hide things which doesn't work in the long term anyway. - neil ] The hack involves copying /vmunix to /tmp/vmunix, patching suser() in the copy of the OS so it always returns true, and rebooting /tmp/vmunix. This is much simpler than other boot-monitor style hacks (eg. patching the credentials in the U-area and continuing). Most machines can't stop you doing this; the new boot proms on Suns are a happy exception. The conditions which make this a problem are: 1) Access to the machine console - easy for most workstations 2) /tmp is a directory on the root file system - true for most workstations, there is probably some chance that on a quiet workstation it would be possible to umount /tmp anyway. 3) /vmunix is readable, or I can import my own copy of /vmunix 4) There is some boot monitor command which allows me to boot a named kernel, in a directory other than / ] A message which I mailed in response to a question about `How can I secure a DECSTATION against single-user boot-up' has been posted to comp.unix-wizards. In it I state that it is possible to break into Sun workstations as root even if they have the console set as not secure (which means they run `/bin/login root' rather than `sh' in single user mode). It wasn't my intention that the person I gave this advice published it. (I didn't explicitly tell him, either, so I guess that's my fault). It is, unfortunately, true. It is also true for most other workstations. Since most manufacturers do not have a fix for this problem I do not wish to publish details of the bug. I have sent in bug reports about this problem to Sun (who have a fix) and DEC (who said that it will be fixed in new models only, no ECO). I also reported it to CERT, but never heard anything back. On Sun workstations, you can prevent this (and some other potential breakins) by: 1) Installing boot prom version >= 2.7.1; on 3/80's you will need prom version >= 3.0 2) Putting a password in the boot prom as described in the SunOS 4.0.3 documentation 3) Making /dev/eeprom non-readable, and making sure there aren't sneak paths to read it (eg. fingerd running as root :-) On other workstations you will have to ask your manufacturer if there is a way of preventing all operations from the console apart from the standard power-up bootstrap. I'm afraid that in most cases, the answer will be no. ------------------------------------------------------------------------ Date: Wed, 06 Sep 89 07:45:35 EDT From: uunet!umiacs.UMD.EDU!steve Subject: Ultrix, r-commands, and the DNS The r-command security problem suggested by unclejack.crd.ge.com!barnett is indeed a problem, though I don't think it's specific to Ultrix. If someone abuses some in-addr.arpa domain somewhere, it seems to me that they can get in. The idea is that domains get delegated by the folks at the NIC to supposedly responsible people. Those people then delegate authority further, again to supposedly responsible people. With luck, there are no bad apples in the bunch. I'm a pessimist: I'm sure that someone will use this attack someday. One possible defense would be to do a gethostbyaddr on the incoming IP address, then do a gethostbyname on that name to get a list of IP addresses. Check the incoming IP address against the ones the nameserver (or YP or /etc/hosts, if you're unfortunate) hands back to you, and if the incoming IP address isn't listed, say no. For example, let's say that I hack the 120.8.128.in-addr.arpa domain so that 3.120.8.128.in-addr.arpa (the address of my workstation) corresponds to decwrl.dec.com. If someone has a .rhosts file somewhere with decwrl.dec.com (possibly with some user name) in it, I'm in: I rlogin later.dude.org -l bogon. rlogind on later.dude.org gets my IP address (128.8.120.3) in accept(), and uses gethostbyaddr to turn that back into a host name (in this case, decwrl.dec.com). rlogind on later.dude.org checks bogon's .rhosts file, and sees that decwrl is in there. rlogind on later lets me in. In my modified scheme, we'd have: I rlogin later.dude.org -l bogon. rlogind on later.dude.org gets my IP address (128.8.120.3) in accept(), and uses gethostbyaddr to turn that back into a host name (in this case, decwrl.dec.com). rlogind does a gethostbyname on decwrl.dec.com, and gets back 16.1.0.1 as the one and only IP address for decwrl. rlogind compares 128.8.120.3 to each element in the list of decwrl's IP addresses, and fails to find a match. rlogind replies, ``intruder alert'', closes the connection, and syslogs the details at high priority. Does this seem reasonable? Is it worth hacking this into existence? The code would be trivial... ------------------------------------------------------------------------ Date: Wed, 6 Sep 89 14:32:13 -0400 From: uunet!MIT.EDU!jon Subject: rlogind/rshd broken by nameserver spoofing in in-addr.arpa domains &fix [ This was was mailed to security-request, rather than security, and has been languishing in my security mailbox for a while - neil ] This brings up a very important point. DNS names and IP addresses should *never* be used for authentication. They are easily forged or faked in a variety of circumstances. The only real solution is to never trust DNS names/addresses and use something like Kerberos. ------------------------------------------------------------------------ Date: Wed, 6 Sep 89 09:23:27 PDT From: Russell Brand Subject: giving-away files >I intend to write a setuid-root C program, which makes the following >checks: > 1) The user invoking must own the file that is being given away > 2) The user invoking must own the directory containing the file > 3) Files may only be given to user IDs greater than 100 > 4) Any setuid/setgid bits will be stripped. Your should realize that #2 doesn't do as much as one might think. ln directory-I-do-not-own/file-I-wish-was-not-mean ~/ give-away ~/file-I-wish-was-not-mean ------------------------------------------------------------------------ Date: Wed, 06 Sep 89 14:21:36 -0400 From: uunet!cs.brown.edu!jb Subject: Re: giving-away files >I intend to write a setuid-root C program, which makes the following >checks: > 1) The user invoking must own the file that is being given away > 2) The user invoking must own the directory containing the file > 3) Files may only be given to user IDs greater than 100 > 4) Any setuid/setgid bits will be stripped. Number 3 above is not valid on all systems. I have been on enough systems where my user ID was less than 100. ------------------------------------------------------------------------ Date: Wed, 6 Sep 89 10:18:16 -0700 From: uunet!pernod.enet.dec.com!francus (Yoseff Francus) Subject: Re: Ultrix 3.0 mount A mount by a normal user will only work via NFS. I believe that NFS is supposed to work that way. The exporting machine can control how much access to allow to an exported file system via options in the /etc/exports file. By default root priveleges do not extend onto NFS links (either using suid or setting it or putting stuff in as root). Granted if the exporting machine allows root priveleges on files it is exporting it could have a serious problem. The standard trick of creating a suid shell on a machine one has root access on and putting it onto an NFS mounted file system will work. However, with proper control of /etc/exports it would seem to me that this is not that big of a problem. Don't other UN*X allow non superusers to mount via NFS?? Incidentally I held this opinion long before I started working for DEC. ------------------------------------------------------------------------ Date: Wed, 6 Sep 89 14:51:43 EDT From: uunet!utzoo!henry Subject: Re: Two security problems with Ultrix 3.0 > 1) Anyone can execute a /etc/mount command... > We fixed this problem by typing > chmod 700 /bin/*mount Unless /bin/*mount was originally set up to run setuid, this is not a solution. Anyone with half a brain can read the relevant manual pages and figure out how to write his own "mount" command. The shutoff has to be at the system-call level, somehow. If the system calls work for anyone, chmoding the commands is just security-through-obscurity, which does not work well. ------------------------------------------------------------------------ Date: Wed, 6 Sep 89 14:46:14 -0400 From: uunet!MIT.EDU!jon Subject: Two security problems with Ultrix 3.0 re: mount I just tried (on a 3.0 system around here) mounting an NFS file system this was and running a setuid program off it. It lost with the message "Restricted operation on file system". What's the big deal? ------------------------------------------------------------------------ Date: Wed, 6 Sep 89 14:40:31 -0400 From: uunet!MIT.EDU!jon Subject: Two security problems with Ultrix 3.0 [ This and the previous message were sent to sec-rqst, instead of to security, I forwarded them - neil ] re: mount What's the problem with making the mount program world-executable? Isn't it the system call that's the problem? If you just get rid of the executable what's to prevent me from copying the mount program from a different system? Or writing my own? (It's not setuid.) Allowing anybody to mount another file system isn't a problem (as long as you are required to own the mount point so you can mount things over /etc, /bin or whatever). But they should be mounted -o nosuid! ------------------------------------------------------------------------ Date: Wed, 06 Sep 89 12:00:14 PDT From: uunet!unclejack.crd.ge.com!barnett Subject: Re: nameserver security hole [ This was sent to sec-rqst instead of to security, I forwarded it - neil ] In Security Digest V1 #31, writes: > Subject: Two security problems with Ultrix 3.0 > 2) name service and remote login > When rlogin/telnet checks to see if someone have permission to log in > without a password, it uses the x.x.x.x.in-addr.arpa name server. > What that means, if I am the Name Server administrator for the > my-network.in-addr.arpa d> omain, I can add an entry saying my name is > decwrl.dec.com or any other name. > If I were to rlogin onto decwrl.dec.com, it asks me what my name is > and I can lie about it It would then believe me. The security hole described is correct, and is present on Sun (as well as any BSD system, I'm pretty sure). The Evil Wizard (W) on site A determines some use for logging in to site B as user X. W creates an account under the name X on site A. Then he sends a rlogin, rsh or rcp request to site B. B ascertains that A2 is authoritative for the number-to-hostname map for the domain containing A, and asks A2 what name goes with the number it saw. A2 lies, specifying the name of B on the likely assumption that it's in /etc/hosts.equiv. Or /.rhosts, if that's what you're into. The rlogin is validated. The solution (in Sun context) is for ypserv to do gethostbyname after it does gethostbyaddr, backmapping the returned name to one or more addresses. It must then compare the incoming address to the addresses from the gethostbyname. If they don't match, it barfs. In the general BSD context, gethostbyaddr can do the gethostbyname. ------------------------------------------------------------------------ Date: Mon, 11 Sep 89 15:52:39 PDT From: neil (Neil Gorsuch) Subject: hosts.equiv stupidity In Sunos and probably a few other operating systems that use the yellow pages, when the operating system is updated or installed, a line containing only "+" is left in /etc/hosts.equiv. The intention is to let yellow pages information be included at that point. The reality is that Sun forgot that there is no yellow pages information for that particular file (hosts.equiv) and that the "+" line lets any hosts ANYWHERE be trusted. So, all you have to do is get a bin login shell on any machine on the network (get root priveleges on a diskless client through any means and then su to bin), and use rcp or rlogin to change any bin owned images. Vendors should really be a little more thorough in in checking what they send out. ------------------------------------------------------------------------ Date: Wed, 13 Sep 89 19:22:26 PDT From: neil (Neil Gorsuch) Subject: list ramblings [ I have sent off requests to all the old isis list members to join. I am now wading through 409 replies (that's AFTER mush seperated out the non-security letters into other folders 8-), so don't expect a speedy response to any security administrative request. I now have all of the old isis list archives. The zardoz list archives, isis list archives, and the many security programs I have recieved are now being put into an automated archive that will only send things to the addresses that recieve the security list. When it is all done, I will send a seperate letter to each list address specifying the exact format of your address that the archive server expects, as well as directions on how to use the archive server. - neil ] ------------------------------------------------------------------------ Date: Thu, 14 Sep 89 19:46:23 PDT From: neil (Neil Gorsuch) Subject: password shadowing This is adapted from a security seminar given by Russell Brand. The main idea is that there is a simple way to have shadow passwords on any unix system supplied by any vendor. While many people disparage the use of shadow passwords, consider the fact that an IBM PC type 386 box can do over 3500 password encryption tries a second. I have seen estimates that it takes anywhere from weeks to months to crack a password this way, but are you comfortable with the idea of someone reading your encrypted passwords, and then having them crack your root password at their leisure? When you use shadow passwords, they can still try this, but then they have to use the system login, which is much slower and will hopefully be noticed. root> mkdir /ETC root> cd /ETC root> chmod 700 . root> cp /etc/passwd PASSWD root> qsubst /etc/passwd /ETC/PASSWD /usr/bin/login /usr/bin/su \ /etc/vipw /usr/bin/passwd /usr/bin/chfn /usr/bin/chsh Or use sed or vi or whatever to change the file name string "/etc/passwd" to "/ETC/PASSWD" in the executable images of the programs that have to modify the /etc/passwd file or read the encrypted password field of the /etc/passwd file. Then put in a crontab entry to run every 5 minutes (or however fast you want changes made to the /ETC/PASSWD file to be propogated to the /etc/passwd file) that executes a shell script that copies /ETC/PASSWD to /etc/passwd but sets the encrypted password field to garbage, maybe something like this: awk /etc/passwd -F: \ '{printf("%s:%s:XXXXXXXXXXXXX:%s:%s:%s:%s\n",$1,$2,$4,$5,$6,$7)}' Or, if you really want to be nasty, put in some kink of hashing function so that the encrypted password field in the produced /etc/passwd file is a function of the user name, so that the cracker wastes weeks or months using bogus data, and then finds that it didn't work 8-). WHEN YOU DO THIS, BE CAREFUL. LEAVE A BUNCH OF WINDOWS OR TERMINALS LOGGED INTO ROOT SO THAT YOU CAN RECOVER FROM A MISTAKE. ------------------------------------------------------------------------ End of Security Digest Volume 1 Issue 32 **********************