Skip to content

F-3.6: Mixed Security Zones via Per-Path SECINFO

Classification

  • Severity: Medium
  • CVSS Vector: Network / Low Complexity / Low Auth Required
  • Affected Versions: NFSv4.0+ servers with mixed sec= settings across subdirectories
  • RFC Reference: RFC 7530 Section 19 (SECINFO)
  • Prerequisite: NFSv4 access to port 2049; export with non-uniform auth flavor settings across subdirectories

Summary

NFSv4 SECINFO probing on subdirectories reveals different authentication flavors than the export root. When the export root requires strong authentication (e.g., sec=krb5) but a subdirectory accepts weaker auth (e.g., AUTH_SYS), an attacker bypasses the stronger requirement by directly accessing the subdirectory with weaker credentials. The SECINFO responses themselves lack integrity protection unless the initial connection uses RPCSEC_GSS, so a MITM can also strip stronger entries from the SECINFO reply.

Technical detail

Per-path SECINFO

RFC 7530 Section 19 defines the SECINFO operation, which returns the list of authentication flavors accepted for a given path. The server can assign different sec= values to different points in the export tree. For example:

/export          sec=krb5        # root requires Kerberos
/export/public   sec=sys         # subdirectory allows AUTH_SYS
/export/internal sec=krb5p       # another subdirectory requires krb5p

When a client issues SECINFO on /export, the server returns [krb5]. When the same client issues SECINFO on /export/public, the server returns [sys]. The client can then access /export/public with AUTH_SYS credentials, bypassing the Kerberos requirement on the parent.

The security zone mismatch

The problem arises when administrators configure per-directory security settings without realizing that subdirectory paths are directly addressable. An attacker does not need to traverse through the export root to reach a subdirectory; NFSv4 COMPOUND operations can target any path in the pseudo-filesystem directly.

The attack sequence:

  1. Issue SECINFO on the export root -- server returns [krb5]
  2. Enumerate subdirectories via READDIR (which may itself require only AUTH_SYS at the pseudo-FS level)
  3. Issue SECINFO on each subdirectory
  4. Identify subdirectories that accept weaker auth flavors
  5. Access those subdirectories directly with AUTH_SYS, bypassing the root's Kerberos requirement

No integrity protection on SECINFO

RFC 7530 S19 notes that SECINFO responses are not integrity-protected unless the connection already uses RPCSEC_GSS. A MITM attacker can modify the SECINFO response to remove stronger flavors, forcing the client to downgrade. This is a separate vector from the per-path mismatch but compounds the risk.

Exploitation

Automated (nfswolf)

nfswolf analyze <target>
# F-3.6 fires when SECINFO on subdirectories returns different
# auth flavors than the export root.
# Evidence: root_flavors=[krb5], mismatched_subdirs=[public=[sys]]

Manual

# 1. Connect to the NFSv4 server
# 2. SECINFO on the export root to get the root's auth flavors
# 3. READDIR to enumerate subdirectories
# 4. SECINFO on each subdirectory to compare auth flavors
# 5. Access any subdirectory that accepts weaker auth

Impact

  • Authentication bypass: Subdirectories accepting AUTH_SYS allow UID/GID spoofing (F-1.1) even when the export root requires Kerberos
  • Data access: Sensitive files in weakly-authenticated subdirectories are fully accessible to any network-reachable attacker
  • False sense of security: Administrators who set sec=krb5 on the export root may believe the entire tree is Kerberos-protected
  • MITM amplification: Without RPCSEC_GSS on the initial connection, SECINFO responses can be tampered with to suppress stronger flavors

Limitations

  • Requires NFSv4 (SECINFO does not exist in v2/v3)
  • The finding only fires when actual flavor mismatches exist; uniform sec= settings across the tree do not trigger it
  • The MITM vector requires an on-path attacker position

Detection

nfswolf: nfswolf analyze walks subdirectories one level deep, issues SECINFO on each, and compares the returned auth flavors against the export root. The finding fires when any subdirectory accepts flavors not accepted by the root.

Server-side: Review /etc/exports for per-directory sec= overrides. Audit NFSv4 pseudo-filesystem configuration for inconsistent security settings. Monitor for SECINFO operations from unexpected clients.

Remediation

  1. Uniform sec= across the export tree: Apply the same authentication requirement at the export level rather than per-subdirectory overrides. Use sec=krb5p at the export root and let it propagate.
  2. Avoid per-path sec= overrides: If different security levels are needed, export the paths as separate exports with their own ACLs rather than using subdirectory-level overrides within a single export.
  3. Use RPCSEC_GSS from the start: Ensure the initial connection uses Kerberos so that SECINFO responses are integrity-protected against MITM modification.
  4. Audit the pseudo-filesystem: Periodically enumerate SECINFO on all exported paths to verify uniform security settings.
Finding Relationship
F-1.1 AUTH_SYS credential forging becomes possible on weakly-authenticated subdirectories
F-1.7 RPCSEC_GSS flavor downgrade: same pattern of weak auth coexisting with strong auth
F-3.4 STRIPTLS: MITM on SECINFO responses is analogous to TLS stripping