Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: NFS Security Problems - What are they? - Can they be fixed?
Keywords: mrroot can be your friend
Message-ID: <1989Dec1.074930.17178@athena.mit.edu>
Date: 1 Dec 89 07:49:30 GMT
References: <21550@adm.BRL.MIL> <1989Nov29.091254.5357@athena.mit.edu> <4166@cayman.COM>
Sender: root@athena.mit.edu (Wizard A. Root)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Distribution: na
Organization: Massachusetts Institute of Technology
Lines: 135

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