Skip to content

F-2.5: Stale Handle After Permission Revocation

Classification

  • Severity: Medium
  • CVSS Vector: Network / Low Complexity / Requires Prior Access
  • Affected Versions: NFSv2, NFSv3
  • RFC Reference: RFC 1094 §1.3, RFC 1094 Appendix A
  • Prerequisite: Client previously had legitimate access; server administrator revoked access

Summary

NFSv3's stateless design means file handles remain valid indefinitely — there is no server-side mechanism to revoke them. When an administrator removes a client from the export ACL or calls UMNT, the file handles already issued to that client continue to work. The UMNT procedure only updates a non-critical advisory list (rmtab), NOT the server's handle validation.

Technical detail

Stateless design

Per RFC 1094 §1.3:

"The NFS protocol is stateless... The mount list information is not critical for the correct functioning of either the client or the server. It is intended for advisory use only."

Handle lifetime

File handles on NFSv3 are persistent by design. They survive: - Client disconnection - Client reboot - Server reboot - Export ACL changes (if handle was issued before the change) - UMNT calls

The revocation problem

Timeline:
1. Admin exports /data to client-A → client-A receives handle H
2. Client-A uses H to read files (legitimate)
3. Admin removes client-A from /etc/exports, runs exportfs -ra
4. Client-A still has handle H
5. Client-A sends READ(H) → server checks handle validity → SUCCESS
   (server checks handle belongs to filesystem, NOT that client is still in ACL)

RFC backing

RFC 1094 Appendix A on UMNT:

"The mount list information is not critical for the correct functioning of either the client or the server."

The server does NOT invalidate handles when UMNT is called. The rmtab entry is removed (advisory), but the handle remains valid for NFS operations.

Impact

  • Revoked clients retain access until the file handle becomes naturally stale
  • NFS3ERR_STALE only occurs when the inode is deleted or the filesystem is reformatted
  • A malicious client can store handles and use them long after authorization is removed
  • Server administrators have no way to force-invalidate handles

Detection (nfswolf)

The scanner should: 1. Test if previously obtained handles work after simulated revocation 2. Report as informational — this is a protocol design limitation, not a misconfiguration

Remediation

  1. Use NFSv4 with leases — server can revoke delegations and invalidate state
  2. Restart the NFS server after revoking access (forces new handles on reconnect, but disrupts all clients)
  3. Use separate filesystems per export — reformatting is the only way to invalidate all handles
  4. Accept the limitation — design access control around Kerberos, not handle revocation