[krbdev.mit.edu #6402] Invalid initial GSSAPI/SPNEGO token can cause segmentation error or assert failure

[Richard Evans via RT]

I've been testing a Java client using SPNEGO against Apache using
mod_auth_kerb.  Apache segfaults with this trace:

#0  0x006ffa25 in spnego_gss_accept_sec_context () from
/usr/lib/libgssapi_krb5.so.2
#1  0x006e3349 in gss_accept_sec_context () from
/usr/lib/libgssapi_krb5.so.2
#2  0x00929769 in kerb_authenticate_user (r=0xb85a1340) at
src/mod_auth_kerb.c:1390
...

The client code has sent slightly invalid ContextFlags for the reqFlags
field in the NegTokenInit (RFC 4178).

This is the sequence which causes the crash.  Code fragments are from
1.6.3.

In spnego_gss_accept_sec_context:


	if (*context_handle == GSS_C_NO_CONTEXT) {
		...
		ret = acc_ctx_new(minor_status, input_token,
				  context_handle, verifier_cred_handle,
				  &mechtok_in, &mic_in,
				  &negState, &return_token);
		if (ret != GSS_S_COMPLETE)
			goto cleanup;

The call to acc_ctx_new fails so the cleanup code is run:

cleanup:
	if (return_token != NO_TOKEN_SEND && return_token != CHECK_MIC)
{
		tmpret = make_spnego_tokenTarg_msg(negState,
sc->internal_mech,
						   &mechtok_out,
mic_out,
						   return_token,
						   output_token);

acc_ctx_new initialises return_token to ERROR_TOKEN_SEND and so the
cleanup code proceeds with the call to make_spnego_tokenTarg_msg.  

At this point 'sc' has not been set, so it still NULL and the reference
to sc->internal_mech segfaults.

The acc_ctx_new call fails because get_req_flags rejects the ASN.1 bit
string sent by the client for the reqFlags.

I've tested with 1.7-alpha1 and this fails at the cleanup code with an
assertion failure:

		assert(sc != NULL);

This client code could cause any server using Kerberos/SPNEGO to fail.

Richard Evans