0 / 5
Network File System (NFS)
NFS is a protocol that lets one computer (the server) share a directory so that another computer (the client) can use it like a local folder. The files stay on the server disk, and the client sends read and write requests over the network. A program opens the file exactly as it would open a local file.
Example: mount the company server's /data folder at /mnt/data on your computer, then open a.txt that lives on the server.
Server's answer: it handles requests from hosts listed in exports.
1 / 5
Server: export a directory to share
The server administrator lists the directory to share, /data, and the client allowed to use it, 192.168.0.10, in the exports file. A client can use only a directory that has been exported this way.
2 / 5
Client: mount the server directory
The client mounts the server's /data at its own folder /mnt/data. The server checks that the requesting host is listed in exports and allows it. After mounting, /mnt/data points to the server's /data.
3 / 5
Program: open /mnt/data/a.txt
The program simply opens /mnt/data/a.txt. The operating system recognizes that this path is on NFS, so it hands the file request to the NFS client instead of the local disk.
4 / 5
NFS client to server: send a read request
The NFS client turns the read request into an RPC (remote procedure call) and sends it to the server. An RPC is a way to call a function that runs on another computer. The server's NFS service receives it on port 2049.
5 / 5
Server to client: return the file content
The server reads /data/a.txt from its own disk and sends the content back as the reply. The program receives it as if it had read a local file. Write requests take the same route. In that case the file on the server disk changes.
1 / 5
Server: a setting open to everyone
The * in exports means every host. The rw option allows both reading and writing. The no_root_squash option makes the server treat requests from the client root as root on the server too. Without it, the default root_squash applies.
2 / 5
Attacker: mount the server directory
The attacker mounts the server's /data at /mnt/data on their own computer. Because exports says *, the attacker's host is among the allowed hosts.
3 / 5
Attacker: write to a file as root
The attacker writes to /mnt/data/a.txt as root (UID 0). Because this is root on their own computer, nothing on the client side stops them.
4 / 5
NFS client to server: send a write request
The write request travels to the server in an RPC together with user ID 0. With AUTH_SYS the server has no way to check whether that ID really belongs to root.
5 / 5
Server: trust UID 0 and process it
The server accepts the user ID 0 it was sent as root on the server. Because of no_root_squash it does not lower the privileges either. As a result, a.txt on the server disk now contains what the attacker wrote.
1 / 4
Server: restrict hosts, writing, and root privileges
Only 192.168.0.10 is listed, so other hosts cannot mount. The ro option allows reading only. The root_squash option turns requests from the client root into an ordinary user ID (65534 by default, nobody).
2 / 4
A host that is not allowed: mount refused
The attacker's host (192.168.0.99) is not in exports. The server refuses the mount request, so the attacker cannot see /data.
3 / 4
An allowed host: write request refused
Even an allowed host cannot write to /data. When the server receives a write request, it checks the ro setting and refuses.
4 / 4
Root on an allowed host: refused because privileges are lowered
When root tries to read secret.txt, the request arrives with user ID 0. The server's root_squash option changes that ID to 65534. The file secret.txt can be read only by root, so the server refuses. The client root does not become root on the server. Requests sent with some user ID other than root are not stopped by this setting, though.
1 / 3
Server: stop nfsd, statd, and lockd
Stop the daemons (services that run in the background) that handle NFS. File requests are handled by nfsd. Restarts of other computers are detected by statd so that locks can be recovered, and file lock requests are handled by lockd. A v3 server also runs mountd, which handles mounting, and rpcbind, which tells clients which ports to use, so check those as well.
2 / 3
Cut off access for the unauthorized system
The server administrator removes the unauthorized host from exports to block its access. A mount that remains on that system has to be removed on that system with umount. This is separate from stopping the service: it cleans up systems that are already attached.
3 / 3
The attacker's request: no service to accept it
Even if the attacker tries to read a file again, no nfsd is there to accept the request on port 2049. With the service off, there is nothing left for an attack to reach even if the settings are sloppy.