Fix leak on GSS module symbol resolution error

If krb5int_get_plugin_func fails, errinfo may contain an allocated
error message.  Free it on error when loading GSS modules.

[ghudson@mit.edu: also fix GSS_ADD_DYNAMIC_METHOD; clarify commit
message]

ticket: 7966 (new)
target_version: 1.12.2
tags: pullup
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
Fix null deref in SPNEGO acceptor [CVE-2014-4344]

When processing a continuation token, acc_ctx_cont was dereferencing
the initial byte of the token without checking the length.  This could
result in a null dereference.

CVE-2014-4344:

In MIT krb5 1.5 and newer, an unauthenticated or partially
authenticated remote attacker can cause a NULL dereference and
application crash during a SPNEGO negotiation by sending an empty
token as the second or later context token from initiator to acceptor.
The attacker must provide at least one valid context token in the
security context negotiation before sending the empty token.  This can
be done by an unauthenticated attacker by forcing SPNEGO to
renegotiate the underlying mechanism, or by using IAKERB to wrap an
unauthenticated AS-REQ as the first token.

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

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

ticket: 7970 (new)
subject: NULL dereference in SPNEGO acceptor for continuation tokens [CVE-2014-4344]
target_version: 1.12.2
tags: pullup
Don't equate IAKERB and krb5 in SPNEGO initiator

To work around a historical bug in Samba, the SPNEGO initiator treats
a counterproposal as matching the optimistic token if both are aliases
for the krb5 mech.  When IAKERB support was added (#6712), IAKERB was
unintentionally added to the set of mech OIDs which were considered to
be krb5 aliases for this purpose.

Remove IAKERB from gss_mech_set_krb5_both and create a new internal
mech set, kg_all_mechs, for use by krb5_gss_indicate_mechs.

ticket: 7974 (new)
Add SPNEGO renegotiation test case

Modify t_spnego.c to force a renegotiation in the SPNEGO exchange, by
making the initiator propose IAKERB while the acceptor supports only
krb5.