Skip to content

F-1.8: AUTH_TOOWEAK Oracle (Kerberos Enforcement Detection)

Classification

  • Severity: Info
  • CVSS Vector: Network / Low Complexity / No Auth Required
  • Affected Versions: NFSv3, NFSv4.0, NFSv4.1, NFSv4.2
  • RFC Reference: RFC 5531 S7.4 (AUTH_TOOWEAK reject status), RFC 2623 S2.3.2 (mount-time GSS bypass)
  • Prerequisite: Export requires sec=krb5 (or krb5i/krb5p) with no AUTH_SYS fallback
  • Kernel Code: fs/nfsd/export.c:check_security_flavor():1183

Summary

When an NFS export is configured with sec=krb5 (or krb5i/krb5p) and no AUTH_SYS fallback, the server rejects AUTH_SYS operations with the RPC reject status AUTH_TOOWEAK. This error is a definitive oracle: it tells an attacker that the export exists, is reachable, and requires stronger (Kerberos) authentication. AUTH_TOOWEAK never fires for a non-existent export or a network-level block, so the response confirms the attack surface without the attacker needing any Kerberos credentials. The MOUNT protocol compounds this because RFC 2623 S2.3.2 exempts root directory operations from GSS enforcement -- MOUNT MNT succeeds with AUTH_SYS even on sec=krb5 exports, leaking the root file handle and full export-root attributes before any Kerberos ticket is presented.

Technical detail

AUTH_TOOWEAK as an export existence oracle

RFC 5531 S7.4 defines AUTH_TOOWEAK as the reject status returned when "the server requires stronger authentication than what the client used." The Linux knfsd path is:

  1. Client sends GETATTR (or any NFS procedure) with AUTH_SYS credentials
  2. nfsd_dispatch() calls check_security_flavor() in fs/nfsd/export.c
  3. check_security_flavor() iterates the export's ex_flavors[] array looking for a match against the client's auth flavor
  4. No match found (AUTH_SYS is not in the list) -- returns nfserr_wrongsec
  5. The RPC layer maps nfserr_wrongsec to RPC_AUTH_TOOWEAK and sends an AUTH_ERROR reply

The error is unambiguous: a different export path (non-existent export, firewalled port, wrong version) would produce MNT3ERR_NOENT, connection refused, or RPC_PROG_MISMATCH. AUTH_TOOWEAK confirms that the export exists, the NFS service is running, and the only barrier is authentication strength.

MOUNT bypass: root handle leak without Kerberos

RFC 2623 S2.3.2 describes an exemption for the MOUNT protocol:

"The mount protocol is not part of NFS and hence does not share the same security framework. [...] An NFS server that allows an AUTH_SYS mount request to succeed for an export requiring RPCSEC_GSS authentication should only allow the client to perform a GETATTR on the root of the export."

Linux knfsd implements this literally: MOUNT MNT with AUTH_SYS succeeds even on sec=krb5 exports. The MNT reply contains:

  • The root file handle (full nfs_fh3)
  • The auth_flavors list (revealing exactly which Kerberos variants are configured)

This leaks:

Leaked Data Intelligence Value
Root file handle Bearer token for the export root -- usable if Kerberos is later obtained or if the server has a separate AUTH_SYS path
auth_flavors list Exact Kerberos configuration (krb5 vs krb5i vs krb5p); presence of AUTH_SYS in the list means F-1.7 applies instead
Root attributes (via AUTH_NONE GETATTR) uid, gid, mode, fsid, fileid of the export root (see F-5.8)

AUTH_TOOWEAK vs MOUNT failure

The oracle's value depends on the sequence:

1. MOUNT MNT /export -> OK (handle + auth_flavors)
   ├── auth_flavors includes AUTH_SYS -> F-1.7 (flavor downgrade), NOT F-1.8
   └── auth_flavors is krb5-only -> proceed to step 2
2. GETATTR(root_handle) with AUTH_SYS -> AUTH_TOOWEAK
   └── Confirmed: Kerberos is enforced on NFS operations
3. AUTH_NONE GETATTR -> may still succeed (RFC 2623 S2.3.2 automounter exemption)
   └── Leaks root attributes without any auth

If MOUNT itself fails (MNT3ERR_ACCES), the export exists but has IP-based ACLs blocking the client. If MOUNT returns MNT3ERR_NOENT, the path does not exist. AUTH_TOOWEAK is the only response that confirms both "export exists" and "stronger auth required."

NFSv4 SECINFO confirmation

On NFSv4, the SECINFO operation returns per-object security flavors. When a client sends a COMPOUND with SECINFO on a Kerberos-only export, the response lists only RPCSEC_GSS entries with their mechanism OIDs (typically 1.2.840.113554.1.2.2 for Kerberos 5). The absence of AUTH_SYS (flavor 1) in the SECINFO response confirms the same finding through a different channel. nfswolf's NFSv4 SECINFO scanner probes this path automatically.

Impact

  • Export enumeration: AUTH_TOOWEAK confirms exports exist behind Kerberos, even when the attacker has no tickets
  • Authentication fingerprinting: The auth_flavors list reveals the exact Kerberos configuration, informing the attacker whether integrity or privacy protection is enforced
  • Handle leakage via MOUNT: The root file handle is obtained without Kerberos, potentially useful if the server is later reconfigured or if a separate vulnerability allows AUTH_SYS operations
  • Metadata leakage: Combined with F-5.8, the export root's uid/gid/mode/fsid/fileid are exposed without Kerberos
  • Attack planning: Knowing which exports require Kerberos vs AUTH_SYS lets an attacker focus on the weakest targets first

Detection (nfswolf)

The analyzer detects AUTH_TOOWEAK through two paths:

  1. MOUNT + GETATTR probe: After a successful MNT call, the analyzer sends GETATTR with AUTH_SYS credentials. If the server responds with AUTH_TOOWEAK, the finding fires. The auth_flavors list from the MNT reply is included in the evidence.

  2. NFSv4 SECINFO scanner: For NFSv4 targets, the scanner issues SECINFO on the export root and decodes the GSS mechanism OIDs. If only RPCSEC_GSS entries are present (no AUTH_SYS), the finding fires with the mechanism list as evidence.

Both checks are passive and do not require Kerberos credentials.

Remediation

  1. Accept the information leak as inherent -- the MOUNT protocol was not designed to hide export existence. Kerberos enforcement is still the correct configuration; the oracle only reveals that it is in place.

  2. Firewall the MOUNT service (TCP/UDP port from rpcbind) to restrict which clients can query exports: 

    iptables -A INPUT -p tcp --dport 20048 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 20048 -j DROP

  3. Use NFSv4 exclusively -- NFSv4 does not use the MOUNT protocol. The pseudo-filesystem root is always accessible, but individual exports can enforce Kerberos via SECINFO without leaking file handles through MOUNT.

  4. Monitor for AUTH_TOOWEAK responses -- a spike in AUTH_TOOWEAK rejections from non-domain hosts indicates reconnaissance. Linux rpcdebug -m nfsd -s proc logs rejected calls.

Finding Relationship
F-1.7: RPCSEC_GSS Flavor Downgrade When AUTH_SYS IS in the auth_flavors list, F-1.7 applies instead of F-1.8
F-5.8: AUTH_NONE Metadata Leak AUTH_NONE GETATTR may still succeed on the root handle obtained via MOUNT
F-5.1: Export List Enumeration EXPORT reveals all paths; AUTH_TOOWEAK confirms which ones are Kerberos-only
F-3.8: RPC-with-TLS TLS transport does not affect AUTH_TOOWEAK -- it operates at a different layer