NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
Extracted elements (27)
Pseudo flavors are introduced because returning RPCSEC_GSS alone in the MOUNT MNT response is insufficient: RPCSEC_GSS encodes many combinations of mechanism, QOP, and service, and the client needs a specific triple to establish the correct security context.
Some NFS server implementations do not require authentication for GETATTR/STATFS (NFSv2) or FSINFO (NFSv3) at mount time because automounters typically run as root and may not have AUTH_DH/AUTH_KERB4/RPCSEC_GSS credentials available; the exposure is limited to file system attribute disclosure.
The description of NFS over Kerberos V5 is limited to the DES MAC MD5 integrity algorithm because MD2.5 is significantly weaker and DES-MAC may not be present in all implementations, as stated in RFC 1964. This simplification ensures interoperability across all compliant implementations.
The NULL procedure must accept AUTH_NONE and AUTH_SYS because RPCSEC_GSS uses the NULL procedure for its own control messages (RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT), so requiring stronger authentication on NULL would break RPCSEC_GSS session establishment.
At least one reference implementation of the Kerberos V5 GSS-API mechanism (MIT) always returns QOP 0 from GSS_Unwrap() and GSS_VerifyMIC() regardless of the actual algorithm in the token, making it impossible for callers to determine the actual integrity algorithm used. NFS implementations MUST NOT exhibit this behavior.
NFS Version 2 had no support for security flavor negotiation; clients had to guess or rely on prior knowledge such as automounter directory service entries. MOUNT Version 3 added flavor negotiation via the MNT procedure response.
WebNFS clients using the public file handle lookup (RFC 2054) do not go through the MOUNT protocol to acquire the initial file handle, rendering MOUNT-based access control ineffective for them. Some servers cope by limiting the public file handle to file systems exported to all Internet clients.
A NFS client SHOULD use the first security flavor in the list returned in the MNT response that it supports, on the assumption that the best access is provided by the first flavor.
An implementation of Kerberos V5 under GSS-API for use under NFS MUST NOT return a QOP of zero from GSS_Unwrap() and GSS_VerifyMIC() regardless of the actual integrity algorithm encoded in the token.
Clients SHOULD NOT assume they will be permitted to alter the <mechanism, QOP, service> triple once the data exchange phase of RPCSEC_GSS has started, as the server MAY lock the triple for the session duration.
NFS clients and servers operating over Kerberos V5 MUST support the DES MAC MD5 integrity algorithm; they SHOULD support the 56-bit DES privacy algorithm.
NFS clients SHOULD attempt to bind to ports < 1024; if they fail, the client MAY attempt the NFS operation over a port >= 1024. NFS servers implementing port monitoring SHOULD provide a method to turn it off.
NFS server implementations SHOULD check the client's authorization on each NFS request, not only at mount time via the MOUNT protocol, to prevent file handle theft or guessing attacks.
NFS servers SHOULD NOT reject NFS requests to the NULL procedure (procedure number 0), and SHOULD accept NULL procedure pings over AUTH_NONE and AUTH_SYS in addition to other RPC security flavors without requiring source port < 1024.
Pseudo flavor numbers MUST be registered via the same method as regular RPC security flavor numbers via [email protected]. The mapping registration MUST contain the pseudo flavor number, an ASCII string name, and the <mechanism, algorithm(s), service> triple.
When using RPCSEC_GSS, the NFS server MUST identify itself via a GSS_C_NT_HOSTBASED_SERVICE name type of the form 'nfs@hostname'.
AUTH_DH uses DES encryption and Diffie-Hellman public key exchange; AUTH_KERB4 uses DES encryption with Kerberos Version 4 secret keys and tickets. Both are based on a network-wide string name and encrypt both credential and verifier.
AUTH_SYS provides the client's effective user identifier, effective group identifier, and supplemental group identifiers on each call. It requires a shared or mapped user/group identifier namespace between client and server.
Pseudo flavors are 32-bit integers allocated from the same number space as regular RPC security flavors. Each pseudo flavor maps to a specific triple of <GSS-API mechanism, quality of protection, RPCSEC_GSS service>, where service is one of rpc_gss_svc_none, rpc_gss_svc_integrity, or rpc_gss_svc_privacy.
RPCSEC_GSS supports M * Q * 3 different styles of security where M is the number of mechanisms, Q is the average number of QOPs per mechanism, and 3 enumerates authentication, integrity, and privacy services.
Existing RPC security flavor string name assignments: AUTH_NONE='none', AUTH_SYS='sys', AUTH_DH='dh', AUTH_KERB4='krb4'. New flavor string names SHOULD be registered with [email protected].
Three Kerberos V5 pseudo flavors are registered: 390003 (krb5, rpc_gss_svc_none), 390004 (krb5i, rpc_gss_svc_integrity), and 390005 (krb5p, rpc_gss_svc_privacy), all using GSS-API OID 1.2.840.113554.1.2.2 with DES MAC MD5 for integrity and 56-bit DES for privacy.
An attacker in the middle during MOUNT Version 3 security flavor negotiation can coax the NFS client into using a weaker security flavor than the server requires, or cause it to use a less-preferred flavor (e.g., without privacy). Using a weak security flavor like AUTH_SYS for the MOUNT query exposes this attack vector.
Host-based access control checked only at mount time allows attackers to circumvent MOUNT server access control by stealing or guessing file handles; impersonating user credentials is trivial with AUTH_SYS but harder with AUTH_DH, AUTH_KERB4, and RPCSEC_GSS.
Locking the RPCSEC_GSS <mechanism, QOP, service> triple per session prevents a denial-of-service attack where a caller specifies integrity or privacy for a file system not exported with those services, causing the RPC subsystem to wastefully perform GSS_VerifyMIC() or GSS_Unwrap().
Port monitoring (requiring source ports < 1024) is at best an inconvenience to an attacker and SHOULD NOT be depended on for security, as many operating systems have no privilege constraints on port binding and physical access trivially grants root privileges.
UNIX uid 0 (superuser) MAY be mapped to a distinguished nobody user (UID_NOBODY) by the server to prevent superuser escalation across NFS. This mapping cannot be avoided for NFS v3 root file systems required for diskless client support; export options restrict superuser access.