NFS no_root_squash Abuse – SUID Shell and SSH Key Injection
When an NFS share is exported with no_root_squash, the server trusts root on the client as root on the server. Any file you write as root on your attack box lands on the share with root ownership. Set the SUID bit on a binary before copying it and any local user on the target can execute it as root.
This is one of the most reliable privilege escalation paths in OSCP labs. You typically discover it from a low-privilege shell on the target by reading /etc/exports, then mount the share from your attack box as root to plant the payload.
Confirming no_root_squash
From a low-privilege shell on the target, read the exports file:
Look for no_root_squash on any exported path:
Any share with no_root_squash is exploitable. Also confirm the share is accessible from your attack box:
Method 1 – SUID bash
The fastest path. Copy /bin/bash to the share as root and set the SUID bit. The local user on the target then runs it with -p to spawn a root shell.
On your attack box as root:
Verify root ownership and SUID bit:
On the target from your low-privilege shell, execute it:
bash-5.1# whoami root
-p preserves the SUID effective UID. You get a root shell.
Method 2 – SUID C Payload
If the target's bash binary is patched to drop SUID privileges regardless of -p (common on hardened systems), compile a C binary that sets UID to 0 and spawns a shell:
On your attack box:
/tmp/suid_shell.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
setuid(0);
setgid(0);
system("/bin/bash -p");
return 0;
}
On the target:
Root shell without relying on bash SUID behaviour.
Method 3 – SSH Key Injection
If the root home directory is exported with no_root_squash, write your public key directly to /root/.ssh/authorized_keys:
On your attack box:
Then SSH directly as root:
If you do not have an SSH key pair yet, generate one first:
When the Share Is IP-Restricted
If /etc/exports restricts the share to a specific IP (e.g. 127.0.0.1 or the target's own subnet), you cannot mount it directly from your attack box. Use SSH port forwarding to tunnel NFS through your existing low-privilege shell:
Forward the NFS port locally:
Mount via the forwarded port on your attack box:
Then proceed with the SUID bash or C payload method as normal. Because the connection appears to originate from 127.0.0.1 on the server side, the IP restriction is satisfied.
Verifying Architecture Before Compiling
If you are compiling a C payload, match the target architecture. Check from your low-privilege shell:
Compile for 32-bit if needed:
To confirm no_root_squash before exploiting, see NFS no_root_squash Detection.
References
-
exports(5) man pagelinux.die.net/man/5/exports (opens in new tab)
NFS export option reference covering root_squash, no_root_squash, and all_squash behaviour.
-
A tale of a lesser known NFS privescwww.errno.fr/nfs_privesc.html (opens in new tab)
Covers the IP-restriction bypass using ld_nfs.so for local-only shares where port forwarding is not viable.
Was this helpful?
Your feedback helps improve this page.