[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478
dwmw2 at infradead.org
Fri Jul 25 06:42:30 EDT 2014
From: David Woodhouse <David.Woodhouse at intel.com>
Servers running Windows 2003 and earlier do not send a negState of
request-mic in their initial reply when the first mechanism is
declined. That's because they implement (roughly) RFC2478, which
predates the addition of the request-mic state.
A server conforming to RFC4178 MUST send request-mic there, but it
is equally clear that on the client side, we should deal with its
absence. For example, the language in §5 (c) is as follows:
"if the negState was request-mic in the first reply from the
target, a mechlistMIC token MUST be included; otherwise..."
In the MIT implementation as it stands, there is no "otherwise".
Because we already overzealously aborted the negotiation.
Other language in RFC4178 which supports this interpretation includes
the whole of Appendix C, which explains the changes since RFC2478.
Looking at that, in fact it seems that the addition of request-mic on
the wire was done specifically to allow interoperability with older
implementations which don't set it. If not for that consideration,
and if we were only ever communicating between RFC4178-compliant
implementations, we could always have just behaved as if request-mic
were set — and there would be no need to *say* so on the wire.
On a practical note, the potential vulnerability which is permitted
by failing to use a MIC is described in §7, and exists anyway when
the selected mechanism doesn't support integrity protection:
"In order to produce the MIC token for the mechanism list, the
mechanism must provide integrity protection. When the selected
mechanism does not support integrity protection, the negotiation is
vulnerable: an active attacker can force it to use a security
mechanism that is not mutually preferred but is acceptable to the
So the vulnerability is that a hypothetical attacker can trick us into
selecting a mechanism that both client and server were prepared to use
anyway, and which the server *would* have accepted if we'd happened to
try it first.
In practice, the viable fallback mechanism is almost always going to be
NTLMSSP. And in the case of HTTP and many other protocols, our
hypothetical attacker would have a much easier way of making the client
use NTLM — just mangle the 'WWW-Authenticate: Negotiate' in the 401
response so that my client only sees the 'WWW-Authenticate: NTLM', and
no need to screw around with SPNEGO packets at all.
(Note: If I could just disable IAKERB, or install the GSS-NTLMSSP plugin
with a sufficiently high priority that it's the first thing we offer to
this server, that would also suffice for me to avoid this problem. As
long as I offer GSS-NTLMSSP first and not IAKERB (which never works in
my environment and only serves to exacerbate other issues such as this
one), I'd be OK.)
src/lib/gssapi/spnego/spnego_mech.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/lib/gssapi/spnego/spnego_mech.c b/src/lib/gssapi/spnego/spnego_mech.c
index 2aa6810..9721cad 100644
@@ -831,17 +831,17 @@ init_ctx_reselect(OM_uint32 *minor_status, spnego_gss_ctx_id_t sc,
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.
+ * A server conforming to RFC4178 MUST set REQUEST_MIC here
+ * but Windows 2003 and earlier implement (roughly) RFC2478
+ * instead, and send ACCEPT_INCOMPLETE.
- if (acc_negState != REQUEST_MIC)
+ if (acc_negState != REQUEST_MIC &&
+ acc_negState != ACCEPT_INCOMPLETE)
sc->mech_complete = 0;
sc->mic_reqd = 1;
- *negState = REQUEST_MIC;
+ *negState = acc_negState;
*tokflag = CONT_TOKEN_SEND;
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5745 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140725/2a92d0a3/attachment.bin
More information about the krbdev