1.  Introduction

Security issues exist when users in an NFS environment use SLIP connection emulation tools such as SLIRP or The Internet Adapter (TIA).  This combination of environment and tools can create a situation in which users can gain access to files normally forbidden to them.  In this document, we discuss the security problem and ways of addressing it.

For a variety of reasons, Internet service providers may choose to give their users only limited access by providing just a shell account.  This gives the user basic text-only processing.  However, users may want full use of the TCP/IP suite of tools including, but not limited to, telnet, FTP, and graphical web browsers.  By using SLIRP or TIA to emulate a SLIP connection, users can gain access to most TCP/IP tools.

In its standard configuration, NFS relies on AUTH_UNIX authentication (a combination of IP address, user ID, and group ID).  This authentication is minimal and can easily be subverted.  In this document, we use SLIRP and TIA as examples of ways the minimal authentication checks can be subverted.

Note that we are not asserting that SLIRP and TIA are nefarious tools; rather, as commonly and legitimately used tools, they serve to illustrate the issues that many sites face.  We are only using these tools to demonstrate the problems inherent in protocols like NFS when AUTH_UNIX-type authentication is used.

 
2.  Definitions

For the purposes of our discussion, we will use the following definitions:

    user:  The person sitting at the keyboard of the dial-in client

    dial-in client:  The PC from which the user dials in

    dial-in server:  The machine the user logs into when the dial-in connection is established. This machine is usually a Unix system, and it authenticates the user and provides SLIP or emulated SLIP service.

    NFS client:  The machine that is a client of an NFS server. In our discussion, it is the same machine as the dial-in server.

    NFS server:  The machine that provides NFS service to the NFS client

    SLIP service:  A protocol that provides for TCP/IP services over a serial line, such as a phone line

 
3.  Background on SLIRP and TIA

When users of shell accounts with an Internet service provider want to extend their capabilities, they can do so by emulating a SLIP connection with tools such as SLIRP or TIA (SLIRP can be replaced with TIA in the rest of this discussion).  To accomplish this, a user dials in to the service provider's network and logs into a shell account on the dial-in server.  From here, the user can start SLIRP, which functions as the remote end of a SLIP connection.  Then the user can use software on her PC to make the emulated SLIP connection.

By using SLIRP, the user does not have to have access to a dedicated SLIP server to get most of the benefits of a true SLIP connection (a few SLIP services have not been emulated in SLIRP and are thus unavailable to the SLIRP user).  The major difference between SLIRP and a true SLIP connection is that the dial-in client does not have an IP address when using SLIRP.  Any requests the user makes to communicate with machines other than the dial-in server are processed by the SLIRP daemon running on the dial-in server, so the requests contain the IP address of the dial-in server as the source address.

 
4.  The NFS problem

In its basic configuration, NFS depends solely upon an IP address and a user name for authentication purposes, meaning that if a user convinces the NFS daemon running on the NFS server that he is Joe User on machine 10.2.3.4, the daemon will give him the access privileges of joe_user on machine 10.2.3.4.  Thus, if a user can masquerade as another user, he can gain access to that other user's files on the NFS server.  The discussion that follows will explain how trivial this is to do.

The workings of NFS are transparent to a user on an NFS client.  The user typically depends on the host operating system to correctly handle system calls (mount, stat, open, read, etc.) to access NFS files and to talk the NFS protocol to the NFS server.  Likewise, the NFS server depends on the NFS client to authenticate the user.  Thus, when the server daemon receives a message that Joe User (uid = 2000, gid = 99) on 10.2.3.4 wants to access /export/home/joe, it makes sure that uid 2000 or gid 99 on 10.2.3.4 has permission to access that directory and then grants the client's request.  The daemon trusts that it really is Joe User on 10.2.3.4 that is requesting access, on the assumption that the NFS client authenticated Joe.

Although the user typically depends on the host operating system to talk to the NFS server, she does not have to.  The user can write a program that will talk the NFS protocol directly to the NFS daemon on the server without needing any special privileges.  She cannot use the mount(1m) command which requires root privileges, but she does not need to use mount(1m) to gain access to files on the NFS server.  Thus, she can masquerade as any user she wants and gain access to that user's files.  Writing a program to talk to the server daemon requires that the user be familiar with the NFS protocol, but the user could just find a tool to do this for her.

SLIRP and TIA are examples of such tools.  When a user dials into an NFS client from his PC and tries to access his files on the NFS server, SLIRP makes the request to the NFS server daemon for him.  SLIRP makes this request with the uid the user has assumed on his PC, not his uid on the dial-in server where SLIRP is running.  Because the user can be anyone he wants to be on his PC, he can pose as any user for the NFS server and access that user's files.

For example, suppose Joe User is logged into his PC as root and he has a SLIRP connection to 10.2.3.4 which is an NFS client.  He is logged in as joe_user on 10.2.3.4 and makes an NFS request.  SLIRP passes the request to the NFS server implying that the request is coming from root@10.2.3.4 because SLIRP sees the request coming from root (on the PC) and appends the only IP address it can, that of the NFS client.  Although the request is really coming from root@PC which is joe_user@10.2.3.4, the NFS server has no such information.  It only knows what it is told by the SLIRP daemon making the request for Joe User.  The SLIRP daemon is just doing its job of passing along requests from the dial-in client.  It is not intended to modify packets from the dial-in client (e.g. to change the username from "root" to "joe_user").

Although NFS can be secured to prevent anyone from posing as root, this is not always done.  Even if this security measure is implemented, NFS does not prevent one user from posing as another non-root user.

 
5.  Securing NFS

Depending on your requirements, the safest and best approach may be to not use a networked file system at all.  O'Reilly's Practical Unix and Internet Security book advocates "questioning your basic assumptions" to make sure that you really do need a networked file system.

If you decide you do need a networked file system, there are several options to choose from.  In addition to NFS, you may consider the Andrew File System (AFS) or the Distributed File System (DFS).  Both AFS and DFS provide secure authentication by requiring that a user hold a token or certificate in order to access files.  Acquiring the token or certificate requires the user to authenticate to an authentication server with a password.  This prevents a user without the correct password from masquerading as another user.  More information about both AFS and DFS can be found on the Transarc public documentation web page, (http://www.transarc.com/afs/transarc.com/public/www/Public/Documentation).

If you choose to use NFS, the suggestions below will help you make it more secure. 

 
5.1  Port Monitoring

Unix systems typically reserve access to low-numbered, privileged ports, allowing only privileged processes to send data out on ports lower than 1024.  On the other hand, the NFS server daemon typically accepts requests that originate from any port on the NFS client.  This is why a non-privileged user can communicate directly with the NFS server daemon, as explained in section 4, The NFS Problem.  This is also why tools such as SLIRP and TIA can communicate with the NFS server daemon even when they are run by a user who does not have special privileges on the NFS client.  However, requiring the NFS server to accept only requests originating from privileged ports will prevent SLIRP and TIA from making unauthorized NFS requests on behalf of the user.
 
Requiring the NFS server to accept only requests from privileged ports can be accomplished by enabling port monitoring on the NFS server via a kernel variable (usually named "portmon," "nfs_portmon," or "nfsportmon") or a switch.  This port checking prevents successful completion of any requests, including all read and stat requests, made to the NFS server via a non-privileged source port.  However, it does not prevent a user from doing an NFS mount since mount requests are handled by the mount daemon and not the NFS daemon.  Some mount daemons (such as the SunOS rpc.mountd) perform their own port checking and are able to disregard requests coming from non-privileged ports.

Enabling port monitoring may prevent some PC implementations of NFS client code from working correctly, and some older implementations of NFS may not function with port monitoring set up.  For these reasons, typically port monitoring is not turned on by default.  On SunOS and Solaris systems, the nfs_portmon variable can be set with the /etc/systems entry "set nfssrv:nfs_portmon = 1".  You should consult your vendor documentation and the man pages for the NFS and mount daemons (typically nfsd(1) and mountd(1)) on your system for more information on enabling port monitoring and on determining if the mount daemon does any port checking for mount requests.  Also, consult the references listed at the end of this document for more details.

 
5.2  Authentication

5.2.1  DES

If possible, (and this may not be practical for all sites) you may choose to use Secure RPC/Secure NFS with AUTH_DES authentication.  With AUTH_DES authentication, a file is kept in the NIS server (/etc/publickey) with an encrypted private key (protected by DES encryption) and a plaintext public key for each user.  When a user wishes to access files through NFS, she must enter her password to authenticate to the NIS server.  Then, her DES encrypted keys are used to authenticate to the NFS server.  Thus, in the Secure RPC environment, users must successfully authenticate themselves before accessing any Secure NFS mounted filesystems.

There are a few drawbacks to this solution.  First of all, not all vendors support AUTH_DES.  Also, although Secure RPC can be implemented without using NIS or NIS+, it is not recommended due to the administrative difficulties of maintaining synchronized /etc/publickey and /etc/netid files on all clients and servers.  Thus, sites that are not currently running NIS or NIS+ would most likely want to implement one of those name services prior to setting up Secure RPC.

In addition, the DES encryption algorithm as used in Secure RPC has been cryptanalyzed by LaMacchia and Odlyzko, showing that it is not completely secure.  In their paper, LaMacchia and Odlyzko prove that it is possible to prepare a database of discrete logarithms that can be used to crack users' keys.  However, the authors state that the preparation of the database requires extensive and sophisticated programming and a few days to run on a fast machine.  Refer to LaMacchia and Odlyzko's paper, "Computation of Discrete Logarithms in Prime Fields,"  (http://www.research.att.com/~bal/papers/crypto/field) for more information.

Despite the drawbacks, using AUTH_DES is preferable to using AUTH_UNIX or AUTH_NONE.

 
5.2.2  Kerberos

Alternatively, you may be able to use Kerberos authentication to add security to NFS.  Kerberos requires a central server to maintain the Kerberos passwords.  It does not use any public key encryption, but instead makes use of multiple levels of DES encryption.  As Kerberos authentication is built into the service and is not just part of the session layer, check your vendor documentation to see if it has been implemented for your NFS service.  As was mentioned in section 5.1, two separate daemons handle mounting and I/O requests, so before relying on Kerberos authentication, be sure to understand whether the implementation you are using authenticates filesystem I/O or the mount process or both.  For more information on Kerberos authentication, see the Kerberos documentation site at MIT (http://web.mit.edu/Kerberos/www/papers.html).
 

5.3  Configuration Issues

In configuring NFS, do not forget the basic security measures that can be taken.  For example, as mentioned at the end of section 4, you can configure NFS to map the root uid (0) to uid "nobody" to prevent root users on NFS clients from having any special privileges for files on the NFS server.  Checklists for other other security-related configuration issues for NFS can be found in CERT Advisory CA-94.15 (http://www.cert.org/pub/advisories/CA-94.15.NFS.Vulnerabilities.html) and in the AUSCERT paper "Unix Security Checklist" (ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist).
 

6.  Additional References

The following resources contain information that is extremely useful in securing a network or a single system.

Managing NFS and NIS, Hal Stern, O'Reilly & Associates, 1991.  ISBN: 0-937175-75-7.

Practical Unix & Internet Security, Simson Garfinkel and Gene Spafford, 2nd edition, O'Reilly & Associates, 1996.  ISBN: 1-56592-148-8.

"UNIX Security Checklist," AUSCERT, available at ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist

CERT/CC book list for more suggested reading, available at http://www.cert.org/other_sources/books.html

 
7.  Acknowledgments

The CERT/CC would like to thank the following for information contributing to this document: Andrew Thomas, Purdue University; James S. MacKinnon, University of Alberta; Cosimo Leipold, Northwestern University; SUN Microsystems.