The NFS 'reserved ports' option and why you care

June 17, 2009

Various NFS servers have various different names for an option to, well, I can do worse than quote the Linux exports(5) manpage:

This option requires that [NFS] requests originate on an Internet port less than IPPORT_RESERVED (1024).

On traditional Unix systems, so called 'reserved ports' can only be used by root. (On non-Unix systems there's often no restriction, which has periodically caused bad Unix protocols some heartburn.)

Why does this option exist, and why does it matter?

Suppose that you're an attacker with a normal Unix login on an NFS client, and the NFS server does not require reserved ports. This means that you can talk to the NFS server yourself with ordinary UDP (or TCP) packets; the client machine is already authorized to talk NFS to the server (at least for filesystems exported to it), and the server isn't noticing the difference between you and the machine's real kernel-based NFS mounts.

This is disastrous. Classic NFS servers trust the UID information that the NFS client sends them (this is the difference between NFS and real network filesystems), and you are in full control of that information; you can make whatever NFS request you want as whatever UID you want, and read the server replies. Congratulations, you can now do anything over NFS that any UID on your client machine can do.

(It's as if you'd compromised the NFS client but without the hassle of actually having to get root.)

The NFS server insisting that NFS requests come from reserved ports on the client machine stops this; as an ordinary user, you can't send packets from reserved ports, and when you send packets from non-reserved ports the NFS server will just ignore them.

(This entry is brought to you by Solaris, the operating system with defaults from 1996 (if not earlier). Turn on nfssrv:nfs_portmon on your Solaris 10 machines today.)

Sidebar: the one technical barrier

In order to talk to an NFS server, you need a valid NFS filehandle, ideally for some directory (because given a directory filehandle, you can walk back through .. to get access to all of the filesystem). There are two ways to get one (ignoring network snooping).

First, you can just ask the server for one via the NFS mount protocol. If the NFS server isn't checking for reserved ports, the server's mountd may not be either, and your machine already has the required permissions in general.

Second, you may be able to make one up by hand. Various NFS servers form NFS filehandles in predictable ways and you can usually find out all or nearly all of the information you need in order to duplicate what the server does. Even if you can't get all of the information you can just start guessing and querying the server to see if you've invented a valid filehandle; typical servers do not log 'invalid filehandle' errors anywhere, because their logs would explode.

Comments on this page:

From at 2009-06-17 19:03:13:

These settings which require reserved ports were much more valuable in days past than they are now, the reason being that any joe schmoe who wants to can install a linux machine.

The difficulty is that a properly configured NFS server will be configured only to export to a specific IP address. You can get around this by a few different ways, whether by arp poisoning or the brute-force override-the-IP.

NFS is just generally insecure. It's supported authentication since v3 (if I remember correctly), but I haven't heard of many people using it, so I'm not sure how widespread that is. v4 looks like it has promising features as well, but again, I haven't heard much noise. I'm going to have to ask around, but most of what I have heard of is legacy application of antiquated methods which are still susceptible to age old vulnerabilities.

Of course, that doesn't stop me from using it on my internal networks. I'm not sure what that says about me, honestly.

Matt Simmons

Written on 17 June 2009.
« Maybe understanding blogrolls
A kernel NFS error message explained »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 17 02:16:03 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.