Code: init_ctx_reselect(OM_uint32 *minor_status, spnego_gss_ctx_id_t sc,
		  OM_uint32 acc_negState, gss_OID supportedMech,
		  gss_buffer_t *responseToken, gss_buffer_t *mechListMIC,
		  OM_uint32 *negState, send_token_flag *tokflag)
{
 	OM_uint32 tmpmin;
 	size_t i;
 
	generic_gss_release_oid(&tmpmin, &sc->internal_mech);
 	gss_delete_sec_context(&tmpmin, &sc->ctx_handle,
 			       GSS_C_NO_BUFFER);
 
	/* Find supportedMech in sc->mech_set. */
	for (i = 0; i < sc->mech_set->count; i++) {
		if (g_OID_equal(supportedMech, &sc->mech_set->elements[i]))
			break;
	}
	if (i == sc->mech_set->count)
		return GSS_S_DEFECTIVE_TOKEN;
	sc->internal_mech = &sc->mech_set->elements[i];

	/*
	 * Windows 2003 and earlier don't correctly send a
	 * negState of request-mic when counter-proposing a
	 * mechanism.  They probably don't handle mechListMICs
	 * properly either.
	 */
	if (acc_negState != REQUEST_MIC)
		return GSS_S_DEFECTIVE_TOKEN;

	sc->mech_complete = 0;
	sc->mic_reqd = 1;
	*negState = REQUEST_MIC;
	*tokflag = CONT_TOKEN_SEND;
	return GSS_S_CONTINUE_NEEDED;
}

Vulnerability Type: DoS Exec Code Mem. Corr. 
CWE ID: CWE-415
Summary: Double free vulnerability in the init_ctx_reselect function in the SPNEGO initiator in lib/gssapi/spnego/spnego_mech.c in MIT Kerberos 5 (aka krb5) 1.10.x through 1.12.x before 1.12.2 allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code via network traffic that appears to come from an intended acceptor, but specifies a security mechanism different from the one proposed by the initiator.
Commit Message: Fix double-free in SPNEGO [CVE-2014-4343]

In commit cd7d6b08 ("Verify acceptor's mech in SPNEGO initiator") the
pointer sc->internal_mech became an alias into sc->mech_set->elements,
which should be considered constant for the duration of the SPNEGO
context.  So don't free it.

CVE-2014-4343:

In MIT krb5 releases 1.10 and newer, an unauthenticated remote
attacker with the ability to spoof packets appearing to be from a
GSSAPI acceptor can cause a double-free condition in GSSAPI initiators
(clients) which are using the SPNEGO mechanism, by returning a
different underlying mechanism than was proposed by the initiator.  At
this stage of the negotiation, the acceptor is unauthenticated, and
the acceptor's response could be spoofed by an attacker with the
ability to inject traffic to the initiator.

Historically, some double-free vulnerabilities can be translated into
remote code execution, though the necessary exploits must be tailored
to the individual application and are usually quite
complicated. Double-frees can also be exploited to cause an
application crash, for a denial of service.  However, most GSSAPI
client applications are not vulnerable, as the SPNEGO mechanism is not
used by default (when GSS_C_NO_OID is passed as the mech_type argument
to gss_init_sec_context()).  The most common use of SPNEGO is for
HTTP-Negotiate, used in web browsers and other web clients.  Most such
clients are believed to not offer HTTP-Negotiate by default, instead
requiring a whitelist of sites for which it may be used to be
configured.  If the whitelist is configured to only allow
HTTP-Negotiate over TLS connections ("https://"), a successful
attacker must also spoof the web server's SSL certificate, due to the
way the WWW-Authenticate header is sent in a 401 (Unauthorized)
response message.  Unfortunately, many instructions for enabling
HTTP-Negotiate in common web browsers do not include a TLS
requirement.

    CVSSv2 Vector: AV:N/AC:H/Au:N/C:C/I:C/A:C/E:POC/RL:OF/RC:C

[kaduk@mit.edu: CVE summary and CVSSv2 vector]

ticket: 7969 (new)
target_version: 1.12.2
tags: pullup