[19057] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

RE: Heap Corruption with large authorization header values

daemon@ATHENA.MIT.EDU (Tim Vega)
Wed Nov 12 19:25:32 2014

From: Tim Vega <tvega@tableausoftware.com>
To: Greg Hudson <ghudson@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu>
Date: Wed, 12 Nov 2014 23:58:25 +0000
Message-ID: <F97DCF8911E6C842975C622C0C8E680F276A3844@S1P5DAG8C.EXCHPROD.USA.NET>
In-Reply-To: <543483EB.8060509@mit.edu>
Content-Language: en-US
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

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@mit.edu] 
Sent: Tuesday, October 07, 2014 5:23 PM
To: Tim Vega; krbdev@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.


_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post