Local buffer too small to hold opaque_auth data in svcauth_gss_validate?

Tomas Kuthan tomas.kuthan at oracle.com
Fri Sep 23 17:50:06 EDT 2016

On 09/23/16 19:12, Greg Hudson wrote:
> On 09/22/2016 04:45 AM, Tomas Kuthan wrote:
>> 299	u_char			 rpchdr[128];
>> This feels unnecessarily limiting. At least since CVE-2007-3999 there is
>> no buffer overflow (lines 311-314), but still, it seems some valid
>> messages might get rejected just because their size exceeds 128.
>> Is there a reason for having the local buffer be 128 B only?
> I have no specific insight into this code, which is really old.  What
> goes into opaque_auth data?  (I looked through the code, but it wasn't
> obvious.)  Is this restriction creating a practical problem?

Hi Greg,

thank you for looking into it.

What goes into opaque_auth data is unclear to me too. There are code 
comments on various places, that suggest it is "raw credentials".
But when I dig into Solaris RPCSEC_GSS flavor code, it looks there is 
just a handle for creds stored elsewhere. I suppose it is security 
flavor dependent...

I am not aware of a practical problem caused by this. I started looking 
into it, when this code was flagged as a (false positive) buffer 
overflow by a static analysis tool.

I'd say there is a theoretical potential for a bug here, as this code 
cannot put up with MAX_AUTH_BYTES of opaque_data, as it should, but it 
is possible no flavor actually uses opaque_data too big to fit.

I am wild about pro-actively 'fixing' this and risking breakage 
elsewhere. What do you think?


More information about the krbdev mailing list