segfault in spnego_mech.c

[Sriram Nambakam]

I was able to reproduce the crash by causing a clock skew on the system.

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Marcus Granado
Sent: Friday, March 06, 2009 11:29 AM
To: krbdev at mit.edu
Subject: segfault in spnego_mech.c

Hi,

I think there's a bug in spnego_mech.c leading to a segfault. The line
numbers here are relative to the release 20899 at
http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssa
pi/spnego/spnego_mech.c?r=20899(the
latest revision of this file in trunk, I believe:
http://src.mit.edu/fisheye/browse/krb5/branches/mskrb-integ/src/lib/gssa
pi/spnego/spnego_mech.c
).

A quick description of the problem:

The function acc_ctx_new()@919 can fail with 3 possibilities in the
return_token parameter:
{INIT_TOKEN_SEND,NO_TOKEN_SEND,ERROR_TOKEN_SEND}.

Now, the function spnego_gss_accept_sec_context()@1199 calls
acc_ctx_new()
at line 1248. If ret != GSS_S_COMPLETE, it goesto cleanup at 1291, checking
for
non-equality of only two possible values in return_token: NO_TOKEN_SEND
and
CHECK_MIC.

If return_token is not any of them, it calls
make_spnego_tokenTarg_msg(),
dereferencing the NULL pointer sc and triggering a segfault! The pointer
sc
is not initialized at this point for two reasons: (1) we jumped over its
initialization on line 1264 when we wentto cleanup at 1291; and (2) we
might be
calling gss_accept_sec_context for the first time with an null
context_handle.

A quick way to test the bug: if the input_token sent to
gss_accept_sec_context() is not null, but an empty buffer (i.e.
GSS_C_EMPTY_BUFFER instead of GSS_C_NO_BUFFER), line 1257 will call
acc_ctx_new() with an empty input_token (len=0) in its buf parameter,
and
send that to get_negTokenInit()@2032 -> g_verify_token_header()@2802,
which
will fail with a G_BAD_TOK_HEADER because the size of the input_token is
0,
causing acc_ctx_new() to return an ERROR_TOKEN_SEND in return_token.

That will cause acc_ctx_new() to fail with a GSS_S_FAILURE and
return_token=ERROR_TOKEN_SEND. We'll be sent to cleanup at 1291, and the
condition (return_token != NO_TOKEN_SEND && return_token != CHECK_MIC)
will
be true, calling make_spnego_toeknTarg_msg() with a NULL sc pointer,
leading
to a crash.

Anyone else able to reproduce that as well?

I believe a solution is to improve the condition above at line 1292,
including also the possible return_token values INIT_TOKEN_SEND and
NO_TOKEN_SEND that can be returned by acc_ctx_new() [btw, I didn't check
what acc_ctx_cont() and acc_ctx_call_acc() could return in
return_token],
but since the algorithm is not trivial, it will take someone
knowledgeable
in the gssapi spec to assert that.

Thanks,
Marcus
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev