Skip to content

F-6.3: SETCLIENTID State Destruction

Status: out of scope for nfswolf. This finding was scoped during the design phase but never implemented; with the lock-DoS module and the NLM/NSM clients removed, all of category 6 (denial of service) is out of scope for nfswolf. This write-up is preserved for reference.

Classification

  • Severity: Medium
  • CVSS Vector: Network / Medium Complexity / No Auth Required
  • Affected Versions: NFSv4.0
  • RFC Reference: RFC 7530 §19, RFC 7931 §5.2.1
  • Prerequisite: Attacker can guess or discover client ID string; no RPCSEC_GSS in use

Summary

In NFSv4.0, the SETCLIENTID/SETCLIENTID_CONFIRM operations manage client identity and state on the server. Without integrity protection (RPCSEC_GSS), an attacker who can guess or discover a client's identity string can issue SETCLIENTID_CONFIRM to destroy the legitimate client's state — invalidating all open files, locks, and delegations.

Technical detail

Client ID lifecycle

Per RFC 7530 §19:

"The operations SETCLIENTID/SETCLIENTID_CONFIRM are responsible for the release of client state."

The sequence: 1. Client sends SETCLIENTID with a unique nfs_client_id4 (owner string + verifier) 2. Server returns a clientid (64-bit opaque value) 3. Client sends SETCLIENTID_CONFIRM to finalize 4. Server commits the new client state

The attack

If an attacker sends SETCLIENTID with the SAME owner string as a legitimate client but a DIFFERENT verifier: 1. Server interprets this as the client re-establishing after a reboot 2. SETCLIENTID_CONFIRM destroys the old client's state 3. All the legitimate client's open files, locks, and delegations are revoked

Owner string predictability

The nfs_client_id4 owner string is typically: - Client hostname + boot time - Implementation-specific but often predictable - Not cryptographically random

RFC 7931 §5.2.1 — Principal Checking

"The server SHOULD record the principal with each confirmed clientid and reject SETCLIENTID_CONFIRM from a different principal."

This mitigation only works with RPCSEC_GSS. Under AUTH_SYS, the "principal" is the unverified machinename — trivially spoofed.

Impact

  • All open files on the legitimate client become invalid (ESTALE-like errors)
  • All locks held by the legitimate client are released (data corruption risk)
  • All delegations are revoked (performance degradation)
  • Applications may crash or corrupt data when their state disappears
  • Can be used to steal delegations or locks from legitimate clients

Detection (nfswolf)

Not implemented. Category 6 (denial of service) is out of scope for nfswolf (see the status banner above); nfswolf has no SETCLIENTID client and no subcommand exercises this finding.

Remediation

  1. Require RPCSEC_GSS for NFSv4 — enables principal checking on SETCLIENTID
  2. Use NFSv4.1+ — EXCHANGE_ID replaces SETCLIENTID with stronger protections
  3. Network segmentation — prevent unauthorized clients from reaching NFS
  4. Monitor for NFS4ERR_CLID_INUSE — indicates state conflict, possibly attack