Subject: [nfsv4] limits for variable-length arrays in NFSv4 XDR?

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 May 2013 18:37:02 -0400 (EDT)

On Tue, 19 Mar 2013, The IESG wrote:

>
> The IESG has received a request from the Network File System Version 4 WG
> (nfsv4) to consider the following document:
> - 'Network File System (NFS) Version 4 External Data Representation
>   Standard (XDR) Description'
>  <draft-ietf-nfsv4-rfc3530bis-dot-x-16.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-04-16. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

I missed the deadline for comments (though it looks like the IESG has not 
discussed this document yet if I am reading the datatracker correctly), 
and this is more a question than a comment, so I'm sending just to the WG 
list.

Many of the variable-length array datat types are provided with a maximum 
length, in particular NFS4_OPAQUE_LIMIT is used in several places; for 
other arrays, though, no limit is supplied, leaving the implementation 
maximum of 2**32-1 octets by default.  This would seem to allow malicious 
clients to cause substantial resource usage on the server (and vice 
versa).  We had a security advisory over in the AFS world that derived 
from an unlimited variable-length array -- the client sent a list of group 
numbers and the server allocated space to send back the group names, and 
since the size of a group name is larger than that of a group number, the 
server's allocation could suffer from an integer overflow and cause a 
crash.  Scanning through the rfc3530bis-dot-x definitions, I don't see 
anything that would trivially do the same, though things like 
COMPOUND4args are a bit suspicious.

Really my question is more general, though -- has thought been put into 
whether or not to leave the default limit for variable-length arrays, or 
did it just stay in place by default?  We're considering limits for 
authentication tokens and GSS negotiation tokens over in AFS-land, and I 
was hoping that there was prior art we could leverage.  RFC 2203 for 
RPCSEC_GSS does not have any limits for the GSS token lengths in its XDR, 
though, so perhaps my hope is ill-placed.

Thanks,

Ben Kaduk

---

From: Nico Williams <[email-masked]>
Date: Fri, 3 May 2013 18:44:42 -0500

I'm of the opinion that no limits should be placed by the protocol
itself on various arrays.  Consider AUTH_SYS.  Not sold yet?  :)

Seriously, today's limits are tomorrow's limitations.  AUTH_SYS'
limitation of 16 groups was a pain, and it didn't even really foster
the deployment of RPCSEC_GSS, and as we discovered, we need to be able
mix AUTH_SYS and RPCSEC_GSS functionality, which is what RPCSEC_GSSv3
does.

Limits should be placed by the recipient.  The fact that a limit is
(or is not) imposed by the spec does nothing to prevent peers from
testing said limit.  "Pentesting doesn't p0wn nodes, hostile peers
p0wn nodes."

Anyways, it'd be OK to recommend some specific limits, or, better yet,
provide a method for clients to discover these limits (e.g., as
properties of the ROOTFH or whatever), or ancillary error information.

Nico
--