NFS Security: a summary

[Tom Chmara]

Sorry for the long delay in actually getting a reply out; between
going on course and losing my feed, it's taken a while to get it
together...

My request dealt with NFS security:  how easy is it to break.
I got a number of replies, most of which had a common theme:  NFS
isn't particularly secure.

Excerpts follow...note that some messages (containing duplicate
information) were not republished.  Referenced messages were not printed
in favour of printing the messages containing the references.
 I appreciate your input, but I'd like to keep this posting as short as I can.

-----------------------------------------------------------------------------

From: arosen at eagle.ulowell.edu (MFHorn)
Date: 14 Aug 88 19:35:46 GMT


An NFS server maps uid 0 from incoming RPC requests to 'nobody', which
is configured into the kernel.  If 'nobody' is set to 0, then anyone
with root access on another machine can get it on yours.  The default
setting for nobody is (in most implementaions) -2.

Also, if you don't export any filesystmes to a particular host, that
host can do nothing to your host even if nobody is set to 0.  [NFS
under Ultrix maps nobody per exported filesystem.]

>From article <23289 at labrea.Stanford.EDU>, by karish at denali.stanford.edu
	(Chuck Karish):
> Some implementations of NFS assume that user ID numbers are congruent
> on server and client.  This means that a bad guy can empower a
> Trojan horse on the remotely-mounted filesystem, then use it from
> the server machine to get privileged access.

If root access is refused (see above), then the bad guy won't be able
to create a set-uid root file on the server.

> Do current versions of NFS provide a way for managers to control mapping
> of user ID's?

The kernel can only map uid 0.  Yellow Pages, a service provided with
NFS, helps managers maintain a network-wide password file.

-----------------------------------------------------------------------------

From: chris at mimsy.UUCP (Chris Torek)
Date: 15 Aug 88 20:47:18 GMT
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

In article <8610 at swan.ulowell.edu> arosen at eagle.ulowell.edu (MFHorn) writes:
>An NFS server maps uid 0 from incoming RPC requests to 'nobody', which
>is configured into the kernel. ... The default setting for nobody is
>(in most implementaions) -2.

This mapping is almost useless.  If I am root on machine sneaky.edu,
and want to be anyone else on machine uptight.edu, all I have to do
is set my uid on sneaky.  Granted, I cannot do anything as uid 0 on
uptight, but I can do anything as anyone else.

>Also, if you don't export any filesystmes to a particular host, that
>host can do nothing to your host even if nobody is set to 0.

*snicker*

Actually, this almost works in some NFS implementations.  In old SunOSes
(I have no current ones so I have no idea if it has been fixed there),
all I have to do is cobble up a request packet that claims my hostname
is one to which you do export some file system, and your mount daemon
will believe me.  It does not even check the Internet address, just the
name I stuff in my request packet!

Even if you fix this, all I have to do is make up a suitable file handle.
That can be anywhere from trivial (passive spying will show some fine
handles) to somewhat hard.  What is needed is real authentication.

-----------------------------------------------------------------------------

From: bnr-di!munnari!cluster.cs.su.oz.au!rex
To: munnari!bnr-di!leibniz!tpc
Subject: NFS security
Cc: oz.au!chris at softway.ARPA

The speaker was quite correct. NFS is broken. From being root an a
machine you can corrupt ANY UNIX machine that has common filesystems
with the initially corrupted machine. There is not one hole, but it is
a collection of holes that all add up to swiss cheese. DO NOT, and I repeat,
DO NOT allow your machines to share filesystems with suspect machines.
Do not allow foreign people onto your machines. If you have the SUNRPC
code underneath your NFS then you are in more trouble. Are you incharge
of security? If so how do I know that you are?

					Rex di Bona.
					rex at cluster.cs.su.oz
					Basser Dept. Comp. Sci.
					University of Sydney, 2006,
					N.S.W. AUSTRALIA.


	/*
	 *  aside:  no, I am not in charge of security; as being one of
	 *  the more UNIX-literate at this site, I've been asked to
	 *  investigate.
	 *  I do, however, consider this a specious inquiry:  in cryptography,
	 *  no algorithm is considered secure whose secrecy relies on the
	 *  secrecy of the algorithm.  Ergo, better disseminate the info
	 *  now, and weep a little less later on.  
	 */
----------------------------------------------------------------------------

Thanks to all for replying.
Hope this information is useful to someone/anyone.

	---tpc---
-- 
------------------------------------------------------------------------
Tom Chmara			UUCP:  ..utgpu!bnr-vpa!bnr-di!leibniz!tpc
BNR Ltd.  			BITNET: TPC at BNR.CA