Changing size of krb5_data's length member

[Marcus Watts]

hartmans at mit.edu (Sam Hartman) writes:
> Currently Kerberos 1.3 uses the same ABI on Unix as the Kerberos 1.2
> series.  
> 
> It is our intent to commit to an ABI for Unix with the 1.3 release.
> We are wondering whether we should change the size of krb5_data.length
> from an unsigned 32-bit length to a size_t.  If we do make this
> change, we would change a few other length fields as well.
> 
> The initial advantage of this seemed to be support for encrypting
> large segments of data (> 4G) into a single encrypteddata PDU.  After
> thinking about this, we believe that  if you are encrypting data that
> large, you probably want  some API that allows streaming and possible
> parallelism.  As such, it is not clear that there is a significant
> benefit to being able to support greater than 32-bits for krb5_data.
> 
> Ken Raeburn is concerned that there may be security implications if
> krb5_data has a 32-bit length and some applications have a 64-bit
> length.  So far we have not actually found such an implication but are
> still searching.
> 
> 
> We are seeking input on this change.  We currently believe that unless
> we find specific advantages for the change, preserving ABI
> compatibility with released code is better than changing the lengths
> of fields in krb5_data.

I think anything that's using a krb5_data to ship more than 4 G of data
around has already got other mondo problems.  Keeping a 32-bit int
sounds fine to me.

The main place where you'd have security implications would be any
place that allows a remote attacker to specify sizes of things.  In k5
itself, the wire protocol and ASN.1 syntax are going to be the places
where that enters the system.  So the main thing to worry about there
would be an attacker supplying an ASN.1 integer that's greater than 32
bits or negative.  If the ASN.1 library still treats signed and
unsigned ints the same, make that 31 bits.  gssapi, telnet, & anything
else that encrypts data on the wire could also have similar issues, but
most of these probably don't use krb5_data or are likely to impose
their own more strict length checks long before they set a krb5_data
length or would think to use a size_t.

I think any k5 application that is willing to generate or accept
krb5_data > 4G in size is probably already fundementally flawed.  At
the very least, even supposing it worked, such an item is likely to
constitute a serious performance bottleneck.  It wouldn't take very
many such items to constitute a denial of service attack, even on a
64-bit machine.  And of course on a 32-bit machine it's just going to
break.  The simplest example I can think of here is the xdr_array bug.

					-Marcus Watts