F-6.1: NLM (Network Lock Manager) Attacks¶

Status: out of scope for nfswolf. The lock-DoS module that exercised this finding was removed, along with the NLM and NSM clients. nfswolf no longer detects NLM registration in the portmapper, runs NLM lock storms, or exposes any NLM/NSM protocol surface. This write-up is preserved for reference; no nfswolf subcommand exercises F-6.1.

Classification¶

Severity: Medium
CVSS Vector: Network / Low Complexity / No Auth Required
Affected Versions: NFSv2, NFSv3 (NLM is separate from NFS protocol)
RFC Reference: RFC 1813 (NLM is specified separately)
Prerequisite: Network access to NLM port (dynamic, obtained via portmapper)

Summary¶

NFSv3 delegates file locking to a separate Network Lock Manager (NLM) protocol running on a dynamic port. NLM cannot be secured with Kerberos — it always uses AUTH_SYS or AUTH_NONE. This means even if NFS is configured with Kerberos authentication (sec=krb5), the lock manager remains vulnerable to spoofing. An attacker can deny legitimate lock requests (DoS), steal locks, or manipulate lock state to cause data corruption.

Technical detail¶

NLM architecture¶

NFSv3 Protocol Stack:
├── nfsd (port 2049)      ← Can use Kerberos
├── mountd (dynamic)      ← Can use Kerberos (partially)
├── NLM/lockd (dynamic)   ← CANNOT use Kerberos (AUTH_SYS only)
├── NSM/statd (dynamic)   ← No authentication
└── rpcbind (port 111)    ← No authentication

NLM provides: - NLM_LOCK — acquire a file lock - NLM_UNLOCK — release a file lock - NLM_TEST — test if a lock would succeed - NLM_CANCEL — cancel a pending lock request - NLM_GRANTED — callback when a blocked lock is granted

Why NLM cannot be Kerberized¶

NLM is a separate RPC program (100021) from NFS (100003). The Kerberos security context established for NFS does not extend to NLM. The protocol was designed before security was a consideration, and retrofitting Kerberos was never accomplished for NFSv3's lock manager.

Attack vectors¶

Lock denial (DoS)¶

An attacker can acquire locks on files that legitimate users need:

# Acquire exclusive lock on target file
nlm_lock(
    target_server,
    file_handle=target_fh,
    lock_owner="attacker",
    offset=0,
    length=0xFFFFFFFF,  # Lock entire file
    exclusive=True
)
# Legitimate users now get NLM_DENIED when trying to lock

Lock stealing¶

Release another client's lock and acquire it:

# Spoof the legitimate client's identity
nlm_unlock(
    target_server,
    file_handle=target_fh,
    lock_owner="legitimate_client",  # Spoofed
    offset=0,
    length=0xFFFFFFFF
)

# Now acquire the lock ourselves
nlm_lock(
    target_server,
    file_handle=target_fh,
    lock_owner="attacker",
    offset=0,
    length=0xFFFFFFFF,
    exclusive=True
)

NSM crash notification spoofing¶

The Network Status Monitor (statd) notifies NLM when a client crashes so locks can be released. An attacker can send fake crash notifications:

# Spoof SM_NOTIFY to make server release all locks held by a client
sm_notify(
    target_server,
    client_name="legitimate-client.internal",
    state=0  # Indicates crash/reboot
)
# Server releases all locks held by that client

Impact¶

Denial of Service: Lock critical files to prevent legitimate access
Data corruption: Break lock protocol assumptions, causing concurrent writes to files that should be serialized
Application failure: Database files, mail spools, and other lock-dependent applications break
Cannot be mitigated by Kerberos: Even fully Kerberized NFSv3 setups are vulnerable

Remediation¶

Migrate to NFSv4: Locking is integrated into the NFS protocol and shares the Kerberos security context
Firewall NLM ports: Restrict access to known NFS clients only

Use fixed NLM port for firewall rules:

# /etc/nfs.conf
[lockd]
port=32803
udp-port=32803

Mount with -o nolock if locking isn't needed (common for read-only mounts)
Network segmentation: Isolate NFS traffic from untrusted networks