Heap Corruption with large authorization header values

[Tim Vega]

Hi Greg,

We ran into another bug of a similar nature

Line 868 of src\lib\gssapi\krb5\accept_sec_context.c:
if ((ctx = (krb5_gss_ctx_id_rec *) xmalloc(sizeof(krb5_gss_ctx_id_rec)))

Would it also be safe to change this xmalloc call to gssalloc_malloc? We're concerned with running into more of the same as well. Is there some sort of systematic rule we can use to determine if it's safe to convert xmalloc calls to gssalloc_malloc?

Tim

-----Original Message-----
From: Greg Hudson [mailto:ghudson at mit.edu] 
Sent: Tuesday, October 07, 2014 5:23 PM
To: Tim Vega; krbdev at mit.edu
Subject: Re: Heap Corruption with large authorization header values

[I've moderated Tim's messages through to krbdev.  I don't plan to moderate them through to kerberos; messages should go to one or the other, not both.]

On 10/02/2014 04:25 PM, Tim Vega wrote:
> Line 1241 of src\lib\gssapi\krb5\accept_sec_context.c:
> token.value = (unsigned char *) xmalloc(token.length);
> 
> This allocates the token which is then deallocated here:
> 
> Line 1790 of src\lib\gssapi\spnego\spnego_mech.c
> gss_release_buffer(&tmpmin, &mechtok_out);
> 
> Changing xmalloc to gssalloc_malloc solves our issue.

I assume you're using a build from source on Windows?

I agree with the description of the bug; this malloc call should have been converted when we introduced gssalloc_malloc.  The bug can't manifest in 1.10.x (and thus in the most recent Kerberos for Windows
release) because it's masked by #1445, which was fixed in 1.12:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=1445

I will go ahead and submit a fix for this; no need to send a separate bug report.