Node:exposed vulnerabilities, Next:, Previous:new vulnerabilities, Up:Security



Vulnerabilities exploitable because of SFS

NFS server security

The SFS read-write server software requires each SFS server to run an NFS server. Running an NFS server at all can constitute a security hole. In order to understand the full implications of running an SFS server, you must also understand NFS security.

NFS security relies on the secrecy of file handles. Each file on an exported file system has associated with it an NFS file handle (typically 24 to 32 bytes long). When mounting an NFS file system, the mount command on the client machine connects to a program called mountd on the server and asks for the file handle of the root of the exported file system. mountd enforces access control by refusing to return this file handle to clients not authorized to mount the file system.

Once a client has the file handle of a directory on the server, it sends NFS requests directly to the NFS server's kernel. The kernel performs no access control on the request (other than checking that the user the client claims to speak for has permission to perform the requested operation). The expectation is that all clients are trusted to speak for all users, and no machine can obtain a valid NFS file handle without being an authorized NFS client.

To prevent attackers from learning NFS file handles when using SFS, SFS encrypts all NFS file handles with a 20-byte key using the Blowfish encryption algorithm. Unfortunately, not all operating systems choose particularly good NFS file handles in the first place. Thus, attackers may be able to guess your file handles anyway. In general, NFS file handles contain the following 32-bit words:

In addition NFS file handles can contain the following words:

Many of these words can be guessed outright by attackers without their needing to interact with any piece of software on the NFS server. For instance, the file system ID is often just the device number on which the physical file system resides. The i-number of the root directory in a file system is always 2. The i-number and generation number of the root directory can also be used as the i-number and generation number of the "exported directory".

On some operating systems, then, the only hard thing for an attacker to guess is the 32-bit generation number of some directory on the system. Worse yet, the generation numbers are sometimes not chosen with a good random number generator.

To minimize the risks of running an NFS server, you might consider taking the following precautions:

mountd -n.

The mountd command takes a flag -n meaning "allow mount requests from unprivileged ports." Do not ever run use this flag. Worse yet, some operating systems (notably HP-UX 9) always exhibit this behavior regardless of whether they -n flag has been specified.

The -n option to mountd allows any user on an NFS client to learn file handles and thus act as any other user. The situation gets considerably worse when exporting file systems to localhost, however, as SFS requires. Then everybody on the Internet can learn your NFS file handles. The reason is that the portmap command will forward mount requests and make them appear to come from localhost.

portmap forwarding

In order to support broadcast RPCs, the portmap program will relay RPC requests to the machine it is running on, making them appear to come from localhost. That can have disastrous consequences in conjunction with mountd -n as described previously. It can also be used to work around "read-mostly" export options by forwarding NFS requests to the kernel from localhost.

Operating systems are starting to ship with portmap programs that refuse to forward certain RPC calls including mount and NFS requests. Wietse Venema has also written a portmap replacement that has these properties, available from ftp://ftp.porcupine.org/pub/security/index.html. It is also a good idea to filter TCP and UDP ports 111 (portmap) at your firewall, if you have one.

Bugs in the NFS implementation

Many NFS implementations have bugs. Many of those bugs rarely surface when clients and servers with similar implementation talk to each other. Examples of bugs we've found include servers crashing when the receive a write request for an odd number of bytes, clients crashing when they receive the error NFS3ERR_JUKEBOX, and clients using uninitialized memory when the server returns a lookup3resok data structure with obj_attributes having attributes_follow set to false.

SFS allows potentially untrusted users to formulate NFS requests (though of course SFS requires file handles to decrypt correctly and stamps the request with the appropriate Unix uid/gid credentials). This may let bad users crash your server's kernel (or worse). Similarly, bad servers may be able to crash a client.

As a precaution, you may want to be careful about exporting any portion of a file system to anonymous users with the R or W options to Export (see export). When analyzing your NFS code for security, you should know that even anonymous users can make the following NFS RPC's on a local-directory in your sfsrwsd_config file: NFSPROC3_GETATTR, NFSPROC3_ACCESS, NFSPROC3_FSINFO, and NFSPROC3_PATHCONF.

On the client side, a bad, non-root user in collusion with a bad file server can possibly crash or deadlock the machine. Many NFS client implementations have inadequate locking that could lead to race conditions. Other implementations make assumptions about the hierarchical nature of a file system served by the server. By violating these assumptions (for example having two directories on a server each contain the other), a user may be able to deadlock the client and create unkillable processes.

logger buffer overrun

SFS pipes log messages through the logger program to get them into the system log. SFS can generate arbitrarily long lines. If your logger does something stupid like call gets, it may suffer a buffer overrun. We assume no one does this, but feel the point is worth mentioning, since not all logger programs come with source.

To avoid using logger, you can run sfscd and sfssd with the -d flag and redirect standard error wherever you wish manually.