Skip to content

F-5.5: NFSv4 Pseudo-Filesystem Structure Leakage

Classification

  • Severity: Low
  • CVSS Vector: Network / Low Complexity / No Auth Required
  • Affected Versions: NFSv4.0, NFSv4.1, NFSv4.2
  • RFC Reference: RFC 7530 §7.3, §7.8
  • Prerequisite: NFSv4 server reachable on port 2049

Summary

NFSv4 uses a pseudo-filesystem to present a unified view of all exports. By starting from the root filehandle (PUTROOTFH) and issuing READDIR operations, an attacker can map the directory structure between exports — revealing server-side directory paths even when no exports are explicitly visible to the client.

Technical detail

NFSv4 pseudo-filesystem

Per RFC 7530 §7.3:

"The pseudo-filesystem provides a view of exported directories."

Unlike NFSv3 (which requires the MOUNT protocol to discover exports), NFSv4 uses a virtual directory tree rooted at /. Exports appear as directories in this tree. The server "creates" virtual directories between the server root and each export to form a navigable path.

Information leakage

When a client issues PUTROOTFH + READDIR, the server returns entries in the pseudo-filesystem. These may include:

  • Directory names along the path to exports (/srv, /data, /home)
  • Export mount points themselves
  • Ancestor directory names that reveal server filesystem layout

RFC 7530 §7.8 — Security Consideration

"Servers SHOULD restrict visibility of the pseudo-filesystem based on the security policies of the exports."

The keyword is SHOULD, not MUST. Many implementations expose the full directory structure between the root and all exports regardless of the client's authorization.

Example

Server /etc/exports:
  /data/project-a  team-a(rw)
  /data/project-b  team-b(rw)
  /home/admin      admin-host(rw)

An unauthorized client querying the pseudo-FS sees:

/
├── data/
│   ├── project-a/    (access denied)
│   └── project-b/    (access denied)
└── home/
    └── admin/        (access denied)

The attacker learns: export paths, directory structure, project names, and username hints — without having access to any export.

Impact

  • Server directory layout revealed to unauthenticated clients
  • Export path names may disclose project names, usernames, or organizational structure
  • Aids targeted attacks (now knows exact export paths to try)
  • Less impactful than NFSv3 MOUNT EXPORT (which reveals ACLs too), but still information leakage

Detection (nfswolf)

The scanner should: 1. Connect to NFSv4 port 2049 2. Issue PUTROOTFH + READDIR to enumerate pseudo-FS 3. Report discovered directory structure as informational finding 4. Compare against MOUNT EXPORT results if NFSv3 is also available

Remediation

  1. Configure server to restrict pseudo-FS visibility (implementation-specific)
  2. Use sec=krb5 per export — well-implemented servers hide exports the client can't authenticate to
  3. Minimize export path depth — /exports/share reveals less than /data/engineering/team-alpha/share
  4. Disable NFSv4 if only v3 is needed — v4 pseudo-FS adds enumeration surface