[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478
nico at cryptonector.com
Mon Aug 4 15:01:16 EDT 2014
On Fri, Jul 25, 2014 at 11:42:30AM +0100, David Woodhouse wrote:
> 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.
Today, yes. It's not clear that this will always be so.
> (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.)
You should be able to gss_set_neg_mechs() to disable offering mechanisms
you can't / don't want to use.
More information about the krbdev