ZZASSGL%cms.manchester-computing-centre.ac.uk@nsfnet-relay.ac.uk (11/28/89)
I am in the process of evaluating a Unix file server system using tcp/ip and nfs. The prospective users have heard stories of nfs security being poor and this is putting them off using the service. As far as I can see nfs is no worse than tcp/ip and Unix itsself as far as security is concerned. Is there something I have missed and should particularly look out for? Geoff. Wot! No fancy signature?
jik@athena.mit.edu (Jonathan I. Kamens) (11/29/89)
In article <21550@adm.BRL.MIL> ZZASSGL%cms.manchester-computing-centre.ac.uk@nsfnet-relay.ac.uk writes: >I am in the process of evaluating a Unix file server system using >tcp/ip and nfs. The prospective users have heard stories of nfs >security being poor and this is putting them off using the service. > >As far as I can see nfs is no worse than tcp/ip and Unix itsself >as far as security is concerned. Is there something I have missed >and should particularly look out for? I can name two significant (and well-known) security problems with many out-of-the-box NFS implementations. Problem one: Many implementations of NFS accept at face value the host name contained in an NFS request when deciding whether the host making the request is allowed to do what it's asking for. If you create an NFS client that lies about its host name in NFS requests, then it can do anything that the host it is claiming to be can do. Example: NFS server A only allows host B to mount filesystems from it. I am on host C, and I really want to get to something that is NFS-exported from host A. I create an NFS client that creates NFS requests with the host name field filled in with B, not with C. I run it on host C, requesting NFS mount access to host A, and presto, I've mounted a directory from host A on C. We have (or had at one point) several clients floating around here at Athena that can attach any filesystem from any NFS server that (a) exports that filesystem to *somebody*, and (b) is running an older version of the NFS code that has the above problem. Many servers still are. The solution to this problem is for the NFS servers to get the host name of the sender of an NFS request from the operating system, not from the NFS request packet. Of course, that can forged as well, but it's a little more difficult. Problem two: Most versions of NFS (a notable exception is NFS with Kerberos extensions, which is what we use here at Athena) do no mapping from client to server other than user ID numbers. If you can mount a filesystem NFS on your machine, and you can become the user ID of some files on that remote filesystem's NFS server, you can read those files. This is great if you're supposed to be mounting the filesystem (for example between machines that all have the same /etc/passwd file and export NFS to each other), but not so good if you're mounting it illicitly, using the above means or whatever other means. Example: NFS server A allows NFS export to everyone. I mount a directory from A on my workstation, then su to root on my workstation and add a dummy entry to the /etc/passwd file with the UID of somebody on A whose files I want to read (but are not world readable). I su to that UID, and presto, I can read those files on A. Caveat: In both of the scenarios above, I've assumed you have root privileges on the machine from which you are trying to do Bad Things. Root privileges just aren't sacred any more on the Internet, or even on most smaller networks. Private workstations have changed all of that. Example (yes, another one :-): We have over 1000 private workstations at Project Athena. They all have the root password 'mrroot'. Everybody (including everybody reading this message :-) knows that root password. So what? All services outside of the workstation are Kerberos-authenticated, so becoming root on the workstation is not a gain in access. It does, however, enable people (if they are smart enough to know how; then again, we have a saying here at MIT that "security by obscurity is no security") to do nasty things to other sites that do respect root privileges, like the NFS hacks described above. Moral: In a small network not connected to a larger Internet of some sort, with machines which are all trusted, with carefully limited /etc/exports files, with a good up-to-date version of NFS, NFS might be considered secure. When you look at "the big picture", it doesn't pan out as well. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
peter@cayman.COM (Peter Schmidt) (12/01/89)
In article <1989Nov29.091254.5357@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: [several well-illustrated paragraphs on two common NFS security problems] > Example (yes, another one :-): We have over 1000 private >workstations at Project Athena. They all have the root password >'mrroot'. Everybody (including everybody reading this message :-) >knows that root password. So what? All services outside of the >workstation are Kerberos-authenticated, so becoming root on the >workstation is not a gain in access. It does, however, enable people >(if they are smart enough to know how; then again, we have a saying >here at MIT that "security by obscurity is no security") to do nasty >things to other sites that do respect root privileges, like the NFS >hacks described above. > Does Kerberos do *all* authentication, or does it concern itself solely with logins? I ask because I had all my files (including bachelor's thesis data) 'rm -r'd by a cheesey little hacker (perjorative meaning here) from my dorm at MIT. That was in the spring of 1988, in the Next House Athena Cluster. Looking at the tracks the custard-head left behind - from lastcomm and my .history (!) - it seems he used the following procedure: 1) He noted that I was logged into a workstation remotely (not encouraged at Athena, but possible with the cooperation of someone at the console. I had logged in on the console, enabled remote login, and gone to my lab, where I logged in remotely to run some trials. Evidently, I was logged out of the console by someone soon after I left.) 2) He su'd to root with the 'mrroot' password. 3) He su'd *to me*. 4) He typed 'rm *', and when this didn't accomplish his goal, he did a 'man rm'. (I'd be laughing now, but it still makes me mad.) 5) He typed 'rm -r *', did an 'ls' to check his success, and then typed 'logout'. 6) He typed 'exit', and logged out of the workstation. Note that the success of this attack hinged on step 3, and this is where my question comes from. When I examined the /etc/passwd on the machine, I found my complete entry had been downloaded. I assumed at the time (someone from Athena feel free to elucidate) that Kerberos downloads the /etc/passwd entry at login time, so that it won't have to be bothered with authentication requests from 'su's, and so that code that expects to find data in /etc/passwd doesn't break. I find this to be a rather large hole for a system that touts its security. And note that the attacker was not particularly smart - his grasp of Unix didn't extend much beyond 'rm', 'ls' and 'su'. Please understand that this isn't a flame at the Athena folks - I was manager of the Next House Cluster, and I highly respect the people in charge of the zoo. When I reported the attack, several people helped track down what happened, and they made a special effort to retrive my files from tape (they weren't all there, but another weekend with the 11/750 in the lab reproduced the thesis data). Techniques for secure distributed computing systems exist, but they are uniformly computationally expensive, since they rely on public-key encryption. Sun will sell you a secure NFS, but even with a DES chip to do the hard work, it is still a lot slower than the standard version. I kind of see that as an evolutionary constraint that encourages maturity in the network community - if we cooperate and are polite, then everyone wins (Gorbachev networking ;-). It's worked pretty well so far. Regards, Peter H. Schmidt, MIT c/o '89 (P.S. for those of you wondering, I didn't haul the guy up on charges because all we had/have is circumstantial evidence, and though I would have loved to have him charged under Federal law, I had a *thesis* to finish. I haven't forgotten, though...) Cayman Systems Inc. | peter@cayman.com 26 Landsdowne St. | ...harvard!mit-nc!winter!pschmidt Cambridge, MA 02139 | (617) 494-1999 | -- Speaking for myself. -- Cayman Systems Inc. | peter@cayman.com 26 Landsdowne St. | ...harvard!mit-nc!winter!pschmidt Cambridge, MA 02139 | (617) 494-1999 | -- Speaking for myself.
jik@athena.mit.edu (Jonathan I. Kamens) (12/01/89)
In article <4166@cayman.COM> peter@cayman.UUCP (Peter Schmidt) writes: >Does Kerberos do *all* authentication, or does it concern itself solely with >logins? All Project Athena service that are in any way privileged are obtained only with kerberos authentication. They included: * Reading and writing files. * Modifying group and mailing list contents. * Sending 'authentic' zephyr notification system messages to other users. * Remote login to other machines without passwords (the kerberos remote login protocol replaces .rhosts files) * Logging in as root on a fileserver or other service-providing machine (unless, of course, you know the root password and can therefore log in with traditional rlogin). * Changing your password. * Posting messages to the discuss conferencing system (our version of notes, you might say, although it wasn't originally written by Project Athena staff), and reading restricted discuss meetings. And I've probably missed a few. >I ask because I had all my files (including bachelor's thesis data) >'rm -r'd by a cheesey little hacker (perjorative meaning here) from my dorm at >MIT. That was in the spring of 1988, in the Next House Athena Cluster. >Looking at the tracks the custard-head left behind - from lastcomm and my >.history (!) - it seems he used the following procedure: > >1) He noted that I was logged into a workstation remotely (not encouraged at >Athena, but possible with the cooperation of someone at the console. I had >logged in on the console, enabled remote login, and gone to my lab, where I >logged in remotely to run some trials. Evidently, I was logged out of the >console by someone soon after I left.) Why do you think that logging in to a workstation remotely is not encouraged at Athena. The security of kerberos depends on the security of a user's kerberos tickets, which are obtained at login. If I can log into a public workstation you're using, I can become root and read your kerberos ticket file, which is stored locally and owned by you. Therefore, I can avail myself of all services available to you, including access to your files, until the tickets expire (8 hours from log in, by default, and they cannot be renewed without the password that created them, which is not part of the tickets). ALL public athena workstations are "access off", meaning that remote log in of any kind is not permitted, unless access is specifically enabled by the person sitting at the console. Once you defeat that on a workstation with a public root password, there is no longer any security. That is why Athena doesn't "encourage" remote logins. >2) He su'd to root with the 'mrroot' password. >3) He su'd *to me*. >4) He typed 'rm *', and when this didn't accomplish his goal, he did a 'man >rm'. (I'd be laughing now, but it still makes me mad.) >5) He typed 'rm -r *', did an 'ls' to check his success, and then typed >'logout'. >6) He typed 'exit', and logged out of the workstation. In order to understand why this was possible, you have to understand some more in addition to the idea of kerberos tickets described above. Kerberized NFS does *not* resend authentication information with each NFS request. Instead, when you log in on a particular workstation and obtain kerberos tickets as part of the log in procedure, the following happens: 1. Your workstation makes a mount request to the fileserver on which your files are stored, and mounts that filesystem. No authentication yet, so you can't read the files at this point. 2. Your workstation makes a mapping request to the rpc mount daemon running on the fileserver. This request includes (encrypted in a manner only the server can decrypt) the information necessary to prove to the server that you are who you say you are. 3. When the server receives this information and verifies its validity, it establishes a mapping in its authentication database between your UID at your workstation and your UID on the fileserver (usually the same thing, but doesn't have to be) and the various groups you are supposed to be in. NOTE: It is important to realize that this mapping is based on two different things: Your UID, and your location. If somebody with your UID tries to write to that fileserver from a different host without authenticating, it won't work. It someone logs in as someone else on your workstation and tries to write to your files, it won't work. So, during your login session, you are "mapped" to your fileserver. When you log out, the mappings are *not* immediately removed; instead, the workstation waits until its five minute deactivate cycle before removing the mappings. The time period between when you walk way from the workstation and when it actually deactivates could give someone enough time to login to the workstation, su to root, su to you, and use your mapping to read from/write to your files. The solution to this is that people who are worried (read paranoid) about security put the unmapping commands in their .logout files and watch them execute before they'll leave the workstation. Now, as for what happened in your particular case. You were logged into the workstation and working away, so your mappings to your fileserver were alive and well. When the guy who blew away your files logged in and su'd to you, he met the two necessary criteria to have access to your files.... the right UID at the right location. >Note that the success of this attack hinged on step 3, and this is where my >question comes from. When I examined the /etc/passwd on the machine, I found >my complete entry had been downloaded. I assumed at the time (someone from >Athena feel free to elucidate) that Kerberos downloads the /etc/passwd entry >at login time, so that it won't have to be bothered with authentication >requests from 'su's, and so that code that expects to find data in >/etc/passwd doesn't break. I find this to be a rather large hole for a system >that touts its security. And note that the attacker was not particularly >smart - his grasp of Unix didn't extend much beyond 'rm', 'ls' and 'su'. The /etc/passwd entry has nothing to do with authentication. It is inserted because Unix counts very heavily on each user having an entry in the /etc/passwd file. Your encrypted password is inserted into the passwd entry because many programs use the /etc/passwd file for local authentication (i.e. "lock" and its X counterparts). The passwd entry had nothing to do with the a**hole in question's ability to impersonate you. The fact that you were logged in with mappings in such a way that someone else could log in on the same machine and su to your UID is what made that possible. The "short story summary" of all this is that machines that allow multiple users must be secure in the traditional unix sense in order for Kerberos authentication from that machine to remain secure as well. Machines that only allow one user at a time do not need to have a secure root and UID namespace. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710