Skip to content

F-3.5: pNFS Metadata Server Detected

Classification

  • Severity: Info
  • CVSS Vector: Network / Low Complexity / No Auth Required
  • Affected Versions: NFSv4.1+ servers with pNFS MDS capability
  • RFC Reference: RFC 5661 Section 18.35 (EXCHANGE_ID)
  • Prerequisite: NFSv4.1 reachable on port 2049

Summary

The server's EXCHANGE_ID flags indicate pNFS metadata server (MDS) capability. GETDEVICELIST reveals the data-server topology, exposing infrastructure that may reside on separate networks or lack equivalent access controls. This is a reconnaissance finding: the topology leak itself is not exploitable, but it reveals attack surface that would otherwise require network scanning to discover.

Technical detail

EXCHANGE_ID pNFS MDS flag

NFSv4.1 EXCHANGE_ID (RFC 5661 S18.35) returns eir_server_impl_id and eir_flags. When the EXCHGID4_FLAG_USE_PNFS_MDS flag is set, the server advertises itself as a pNFS metadata server. This means the server delegates data I/O to one or more data servers (DS), and the client can obtain layout information to contact those data servers directly.

GETDEVICELIST topology disclosure

Once MDS capability is confirmed, GETDEVICELIST enumerates all device IDs known to the metadata server. Each device ID maps to a data server with its own network address, NFS version, and transport configuration. The response reveals:

  • Data server IP addresses and ports
  • Transport protocols (TCP, RDMA)
  • The number of data servers in the cluster
  • Device ID allocation patterns (sequential on Linux knfsd, per nfsd_devid_seq)

Why data servers matter for security

pNFS data servers handle the actual file I/O. They may:

  • Reside on a different network segment with weaker firewall rules
  • Accept AUTH_SYS on the data path even when the MDS requires Kerberos (see flex-file layout behavior)
  • Lack the same export ACL enforcement as the MDS
  • Expose additional attack surface (separate NFS instances, different patch levels)

The topology leak gives an attacker a map of backend infrastructure without any port scanning.

Exploitation

Automated (nfswolf)

nfswolf analyze <target>
# F-3.5 fires when EXCHANGE_ID flags show pNFS MDS capability.
# Evidence includes server_flags, device_count, and device_ids.

Manual

# 1. Confirm pNFS MDS via EXCHANGE_ID flags
#    Look for EXCHGID4_FLAG_USE_PNFS_MDS in the response

# 2. Enumerate data servers via GETDEVICELIST
#    Each returned device_id can be resolved via GETDEVICEINFO
#    to obtain the data server's network address and configuration

# 3. Scan/probe the discovered data server IPs for additional attack surface

Impact

  • Topology disclosure: Reveals backend data server addresses that may not be directly reachable or known to the attacker
  • Attack surface expansion: Each data server is a separate NFS instance that may have weaker security posture
  • Reconnaissance value: Eliminates the need to scan for backend NFS infrastructure

Limitations

  • Requires NFSv4.1 support (not NFSv4.0)
  • The data servers may be on isolated networks unreachable from the attacker's position
  • The finding is informational; no direct exploitation occurs from the topology leak alone

Detection

nfswolf: nfswolf analyze performs NFSv4.1 EXCHANGE_ID and checks for the pNFS MDS flag. When present, GETDEVICELIST enumerates device IDs and reports the topology.

Server-side: Monitor for EXCHANGE_ID and GETDEVICELIST operations from unexpected clients. These are legitimate protocol operations, so detection requires baselining normal client behavior.

Remediation

  1. Disable pNFS on exports where topology confidentiality matters. Remove the pnfs export option.
  2. Network segmentation: Place data servers on isolated network segments with strict firewall rules. Do not assume that hiding data servers behind the MDS is sufficient if GETDEVICELIST reveals their addresses.
  3. Equivalent security posture: Ensure data servers enforce the same authentication requirements (e.g., sec=krb5) and export ACLs as the metadata server.
  4. Monitor DS access: Log connections to data server ports and alert on unexpected source IPs.
Finding Relationship
F-1.1 AUTH_SYS credential forging on the data path if DS accepts AUTH_SYS
F-5.4 RPC service enumeration via portmapper; pNFS topology is a deeper form of service discovery