F-5.8: Export Root Attributes Leaked via AUTH_NONE¶

Classification¶

Severity: Low (Information Disclosure)
CVSS Vector: Network / Low Complexity / No Auth Required
Affected Versions: NFSv2, NFSv3
RFC Reference: RFC 2623 S2.3.2 (AUTH_NONE for automounter GETATTR)
Prerequisite: Valid file handle for the export root (obtained via MOUNT)

Summary¶

Many NFS servers accept GETATTR calls with AUTH_NONE (auth_flavor 0) on mounted file handles, returning full fattr3 metadata -- uid, gid, mode, file size, link count, timestamps, fsid, and fileid -- without any credentials. RFC 2623 S2.3.2 explains this exists to support the automounter, which needs to stat export roots before deciding whether to mount them. An attacker uses this leak to map export ownership, identify writable directories, and harvest UIDs/GIDs for credential spoofing without sending any authenticated request.

Technical detail¶

AUTH_NONE GETATTR response¶

A GETATTR call with auth_flavor=0, auth_body=<empty> returns full file attributes when accepted:

fattr3 {
  type      = NF3DIR
  mode      = 0755
  nlink     = 14
  uid       = 0          <- export root owner
  gid       = 0          <- export root group
  size      = 4096
  used      = 4096
  rdev      = (0, 0)
  fsid      = 64769
  fileid    = 2          <- inode number (root inode = 2 on ext4)
  atime     = 2024-11-15 08:30:00
  mtime     = 2024-11-14 22:15:33
  ctime     = 2024-11-14 22:15:33
}

What an attacker learns¶

Field	Intelligence Value
uid/gid	Export owner identity -- first target for UID spoofing
mode	Whether "other" has read/write/execute access
fileid	Inode number (2 = filesystem root, higher = subdirectory export)
fsid	Filesystem identifier -- correlate exports on the same volume
nlink	Subdirectory count (nlink - 2 = number of child directories)
atime/mtime	Activity pattern -- when the export was last accessed/modified
size	Directory size hints at entry count

Fileid as an escape indicator¶

If fileid = 2, the export root is the filesystem root inode. Combined with the fsid, this tells the attacker: - No bind-mount indirection -- LOOKUP .. may reach the real parent - Escape handles (see F-2.1) target inodes on the same fsid

If fileid > 2, the export is a subdirectory -- the root inode (2) is above it and may be reachable via handle brute-force.

Why AUTH_NONE works¶

RFC 2623 S2.3.2:

"The automounter must be able to perform GETATTR on the root of an export to determine whether to proceed with mounting."

Most implementations honor this for backwards compatibility. Linux knfsd accepts AUTH_NONE GETATTR on the export root even when sec=sys is configured. Only sec=krb5 (or stricter) with no_root_squash absent will reject AUTH_NONE outright on some implementations.

Impact¶

Export ownership and permissions revealed without any credentials
UIDs/GIDs harvested for targeted spoofing (see F-1.1)
Filesystem layout deduced from fsid/fileid correlation
Activity patterns exposed via timestamps
No authentication artifacts left in server logs (AUTH_NONE may not be logged)

Detection (nfswolf)¶

The analyzer sends a GETATTR call with AUTH_NONE credentials (auth_flavor=0, empty auth body) using the file handle obtained from a prior MNT call. If the server returns NFS3_OK with valid fattr3 data, the finding fires. The check is passive and does not modify any server state.

The scanner also uses AUTH_NONE GETATTR during the recon phase to fingerprint export roots before attempting authenticated access.

Remediation¶

Restrict AUTH_NONE access -- configure sec=krb5 to reject unauthenticated calls:
```
/srv/share  client(rw,sec=krb5)
```
Use sec=sys with root_squash -- AUTH_NONE is squashed to anonuid/anongid, but GETATTR still succeeds on most implementations
Firewall mountd -- if the attacker cannot obtain a file handle via MOUNT, AUTH_NONE GETATTR has no handle to query
Migrate to NFSv4 -- the pseudo-filesystem root does not require MOUNT, but GETATTR on the pseudo-root still leaks metadata; combine with sec=krb5