Skip to content

F-3.8: RPC-with-TLS Supported (AUTH_SYS Still Forgeable)

Classification

  • Severity: Info
  • CVSS Vector: N/A (informational finding)
  • Affected Versions: Servers that accept AUTH_TLS NULL probe (RFC 9289)
  • RFC Reference: RFC 9289 S4.1 (AUTH_TLS STARTTLS handshake), RFC 9289 S6.3 (AUTH_SYS inside TLS)
  • Prerequisite: Network access to NFS port (2049)

Summary

RPC-with-TLS (RFC 9289) encrypts NFS traffic at the transport layer, preventing passive sniffing and credential theft from the wire. However, TLS only protects the pipe; it does not authenticate the user. AUTH_SYS credentials inside a TLS tunnel are still client-asserted and trivially forgeable. A client that establishes a TLS connection can claim any UID/GID, and the server has no way to verify the claim. Mutual TLS (mTLS) is recommended by the RFC but not required, so most deployments provide server authentication only.

Technical detail

The AUTH_TLS handshake

Per RFC 9289 S4.1:

1. Client -> Server:  NULL RPC with auth_flavor=7 (AUTH_TLS)
                      verifier body = "STARTTLS" (7 bytes)
2. Server -> Client:  Reply with STARTTLS verifier (TLS supported)
                      -- or AUTH_REJECTED (TLS not supported)
3. Client <-> Server: TLS handshake on the existing TCP connection
4. All subsequent RPC traffic is encrypted

The initial probe is cleartext. See F-3.4 for the STRIPTLS downgrade risk.

AUTH_SYS inside TLS

RFC 9289 S6.3 states:

"The use of AUTH_SYS with peer authentication is problematic because AUTH_SYS does not include a secure user authentication mechanism."

With TLS established, a client can still send:

AUTH_SYS { uid=0, gid=0, groups=[0], machinename="trusted-host" }

The server cannot distinguish this from a legitimate root request. TLS proves the client holds a certificate (if mTLS is enforced) or nothing at all (server-only TLS). It never proves which user is making the call.

Mutual TLS vs server-only TLS

Mode Wire Encryption Client Identity UID Forgery
No TLS None None Trivial
Server-only TLS Yes Unverified Trivial (inside tunnel)
Mutual TLS Yes X.509 certificate Still possible unless server maps certs to UIDs
RPCSEC_GSS (krb5p) Yes Kerberos principal Not possible

Even mTLS only proves "this machine holds certificate X." Mapping X.509 subjects to Unix UIDs requires server-side policy that most implementations lack.

Impact

  • Transport encryption prevents passive sniffing (positive)
  • UID/GID spoofing remains fully viable inside the TLS tunnel
  • Admins may assume TLS provides user authentication, but it does not
  • Absence of mTLS means any client can establish a TLS session

Detection (nfswolf)

The scanner sends a NULL RPC call on port 2049 with: - auth_flavor = 7 (AUTH_TLS) - Verifier body = "STARTTLS" (0x53 54 41 52 54 54 4c 53, 8 bytes, no NUL)

If the server replies with a STARTTLS verifier, nfswolf reports RPC-with-TLS as supported and notes the AUTH_SYS-inside-TLS caveat. The scanner does not complete the TLS handshake; it only probes for support.

Remediation

  1. Enable mutual TLS -- require client certificates to limit which machines can connect: 

    # /etc/nfs.conf (Linux 6.7+)
[nfsd]
tls-verify-peer=1
tls-required=1

  2. Use RPCSEC_GSS (krb5p) for user-level authentication: TLS protects the transport, Kerberos protects the identity

  3. Deploy DANE/TLSA records to prevent STRIPTLS downgrade (see F-3.4)

  4. Do not rely on TLS alone as a replacement for sec=krb5; they solve different problems