F-5.17: Write Verifier Changed Between Probes (Server Reboot Detected)

Classification

• Severity: Medium (Operational Intelligence)
• CVSS Vector: Network / Low Complexity / No Authentication Required
• Affected Versions: NFSv3
• RFC Reference: RFC 1813 Section 3.3.21 (COMMIT writeverf3)
• Prerequisite: Writable export, or server that accepts COMMIT without a prior WRITE

Summary

The writeverf3 verifier returned by the COMMIT procedure changes when the NFS server reboots or the NFS service restarts. By issuing two COMMIT calls separated in time and comparing the returned verifiers, an attacker detects server reboots without any privileged access. A detected reboot has operational consequences: unstable writes from other clients may have been lost, NLM lock state was reset, and the NFSv4 grace period has started.

Technical detail

RFC 1813 Section 3.3.21 defines the COMMIT procedure and its writeverf3 return value:

"The server returns a write verifier upon the successful completion of a COMMIT. This verifier allows the client to detect one case where the server could have lost the data."

The verifier is an 8-byte opaque value that the server generates at startup and holds constant until the next restart. Any change in the verifier proves the server restarted.

Probe sequence

Probe 1:
  COMMIT(file_handle, offset=0, count=0)
  -> writeverf3 = 0xA1B2C3D4E5F60718

(time passes)

Probe 2:
  COMMIT(file_handle, offset=0, count=0)
  -> writeverf3 = 0x9876543210ABCDEF

Verifier changed -> server rebooted between probes.

The COMMIT call with offset=0, count=0 asks the server to flush all pending writes for the file. Even if there are no pending writes, the server returns the current writeverf3.

What a reboot reveals

Consequence	Attacker relevance
Unstable writes lost	Clients that used UNSTABLE write mode and did not COMMIT may have lost data
NLM locks reset	All byte-range locks held by all clients were dropped on restart
NFSv4 grace period	New OPEN and LOCK operations are temporarily blocked while the server recovers state
Stale handles possible	File handles referencing deleted-then-recreated files may now point to different inodes
Credential cache stale	Cached credential escalation results should be re-validated

By sampling writeverf3 at regular intervals, an attacker builds a reboot timeline for the server, revealing maintenance windows, stability problems, and patch cycles.

Exploitation

Automated (nfswolf): nfswolf analyze issues two COMMIT calls against the export root handle and compares the returned writeverf3 values. A mismatch triggers this finding at Medium severity.

Manual:

# Using nfswolf shell:
nfswolf shell target:/export

# Issue COMMIT and note the verifier (visible in debug output):
> commit .
# writeverf3: a1b2c3d4e5f60718

# Wait, then re-issue:
> commit .
# writeverf3: 9876543210abcdef
# Different = server rebooted

Impact

• Detects server reboots without privileged access or server-side monitoring
• Reveals maintenance windows and stability patterns
• Signals that cached state (handles, credentials, locks) may be stale

Limitations

• Only works on NFSv3 (NFSv4 uses a different state model with sessions and lease recovery)
• Requires a writable export, or a server that does not reject COMMIT on a read-only export
• The verifier only changes on full restarts; configuration reloads (exportfs -r) do not change it
• Two probes at the same instant always match; a time gap is needed to detect reboots

Detection

No server-side mechanism detects COMMIT-based probing. The calls are indistinguishable from normal client behavior.

Remediation

1. Use NFSv4 -- NFSv4 sessions provide explicit state recovery mechanisms that are less information-leaky than the writeverf3 probe
2. Read-only exports -- COMMIT on a read-only export returns NFS3ERR_ROFS on most implementations, blocking this probe
3. Awareness -- the finding is informational reconnaissance; the primary defense is limiting what the attacker can do with the reboot knowledge (Kerberos, separate filesystems, restrictive squashing)