Skip to content

F-1.7: RPCSEC_GSS Flavor Downgrade (Mixed-Flavor Export)

Classification

  • Severity: High
  • CVSS Vector: Network / Low Complexity / No Auth Required (active downgrade requires MITM)
  • Affected Versions: NFSv3, NFSv4.0, NFSv4.1, NFSv4.2
  • RFC Reference: RFC 2203 §5.2.1, RFC 7530 §19, RFC 2623 §5
  • Prerequisite: Server exports with both AUTH_SYS and krb5 flavors

Summary

When an NFS server advertises both AUTH_SYS and RPCSEC_GSS (krb5/krb5i/krb5p) on the same export, an attacker can choose the weaker flavor. No negotiation forces the stronger mechanism. A MITM can also tamper with the MOUNT response or SECINFO results to remove krb5 entries, forcing a legitimate client onto AUTH_SYS. This is distinct from F-1.6 (NFSv2 version downgrade) -- the attacker stays on the same NFS version but downgrades the security mechanism.

Technical detail

No mandatory flavor negotiation

RFC 2203 §5.2.1: "There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API mechanism identifiers or QOP values." The protocol offers a menu of security flavors; the client picks one. Nothing forces the strongest option.

Three attack vectors

1. Direct selection (no MITM needed): If the server's export options include sec=sys:krb5:krb5i:krb5p, an attacker simply sends AUTH_SYS credentials. The server accepts them because AUTH_SYS is in the list. This is the common case -- many administrators add sec=sys as a fallback for clients without Kerberos.

2. MOUNT flavor list tampering (MITM): RFC 2623 §5 documents this: "unless the client uses a strong security flavor in the MOUNT protocol query, an attacker in the middle could cause the client to use the weaker form of security." The MOUNT MNT response carries an auth_flavors list. Since the MOUNT query itself is typically sent with AUTH_SYS, the response is tamperable -- a MITM removes krb5 entries, leaving only AUTH_SYS.

3. NFSv4 SECINFO tampering (MITM): RFC 7530 §19 warns that "without integrity protection... SECINFO information is subject to downgrade attacks." A MITM intercepts SECINFO responses and removes krb5 entries. Without RPCSEC_GSS integrity on the SECINFO call itself, the client has no way to verify the response.

Why this matters

Kerberos deployment is expensive (KDC infrastructure, keytabs, DNS). Administrators often add sec=sys as a transitional fallback, intending to remove it later. The fallback persists indefinitely. The export appears to have Kerberos, but any attacker with network access can bypass it entirely by selecting AUTH_SYS.

Impact

  • All AUTH_SYS identity attacks (F-1.1 through F-1.4) apply despite Kerberos being "configured"
  • Administrator false sense of security -- Kerberos is deployed but not enforced
  • MITM can force even well-configured clients onto AUTH_SYS

Detection (nfswolf)

The analyzer checks: 1. MOUNT MNT response auth_flavors list for presence of both AUTH_SYS (1) and any krb5 variant (6/390003/390004/390005) 2. NFSv4 SECINFO per directory for mixed flavors 3. Reports as High when both weak and strong flavors coexist

Remediation

  1. Remove sec=sys from exports that have Kerberos -- use sec=krb5 (or krb5i/krb5p) exclusively
  2. If AUTH_SYS fallback is needed temporarily, restrict the export to trusted subnets and set a deadline for removal
  3. Use sec=krb5p for both the export and the MOUNT query -- prevents MITM tampering of the flavor list
  4. NFSv4: Use RPCSEC_GSS integrity on SECINFO calls to prevent SECINFO downgrade
Finding Relationship
F-1.1: UID/GID Spoofing Enabled by downgrading to AUTH_SYS
F-1.6: NFSv2 Downgrade Version-level downgrade; F-1.7 is flavor-level downgrade
F-3.1: Plaintext Wire Protocol MITM prerequisite for active downgrade
F-3.4: STRIPTLS Downgrade Transport-level downgrade; F-1.7 is auth-level downgrade