NFS Security Problems - What are they? - Can they be fixed?

[Jonathan I. Kamens]

In article <21550 at adm.BRL.MIL>
ZZASSGL%cms.manchester-computing-centre.ac.uk at 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 at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710