[19499] in Kerberos_V5_Development
Re: Local buffer too small to hold opaque_auth data in
daemon@ATHENA.MIT.EDU (Tomas Kuthan)
Fri Sep 23 17:50:14 2016
Message-ID: <57E5A38E.2000905@oracle.com>
Date: Fri, 23 Sep 2016 23:50:06 +0200
From: Tomas Kuthan <tomas.kuthan@oracle.com>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>, krbdev@mit.edu
In-Reply-To: <6416ec8d-f3ce-5cf3-0132-7e92be467d51@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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?
Thanks,
Tomas
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
