Στις 05/08/2017 09:52 πμ, ο Amos Jeffries έγραψε:
On 01/08/17 04:40, Alex Rousskov wrote:
On 07/31/2017 09:24 AM, Amos Jeffries wrote:
To do so otherwise would randomly
allow replay attacks to succeed
Please give a specific example where the proposed changes would allow a
new kind of replay attacks to succeed, given a correctly functioning
Squid and a correctly functioning helper. I cannot think of any
realistic examples, but this is not my area of expertise.
In NTLM the TT (type-2) tokens are generated by a particular helper and
only that helper can authenticate the corresponding KK (type-3) token.
Annoyingly NTLM does not authenticate the client, nor the HTTP message
it is attached to - it is specifically (and only) authenticating that
the TCP connection is being used by the specific end-client able to
generate the KK token proof-of-identity.
With the current code reserved helpers are tied to a particular TCP
connection through Auth::UserRequest. As such an attacker would have to
inject replay attempts into the same TCP connection the client was
using. Which is protected by the TCP SEQNO mechanism - not impossible to
subvert, but a high difficulty level.
Any attempt to send the KK on another TCP connection would reach a
different helper and be rejected as a 'secret' value embedded in the TT
was reserved by the originating helper >
With the proposed changes all an attacker needs to do is peek at the KK
token from the client then race it to be the first one to deliver any
token to the originating helper (which can succeed at or after reuse
timeout) - using as many other TCP connections as it likes. Which is a
MUCH easier thing to do than SEQNO subverting. >
As far as the TT generating helper is concerned there is no difference
between an attackers KK token after timeout, or Squid just waiting some
period timeout+N until the real clients KK token arrived.
And as I mentioned earlier there are other things the attacker can do to
slow traffic down and bias the race towards itself. Those things do not
have any effect on the client TCP connection use of SEQNO - so are
relatively benign with the current code.
Note that under the attack conditions the TT generating helper *does
not* receive a fresh YR query which it might use to reset its
If I am not wrong this is prevented by ntlm/UserRequest.cc code.
The ntlm/* code for each new connection:
1) expects a type1 message in Authorization header (and send a YR
request to helper)
2) sends back to the client a type2 message in WWW-Authenticate header
3) expects a type3 message in Authorization header (and send a KK
request to helper)
If squid did not receive with that order the authentication info from
the client will just reject/deny the connection.
The ntlm helpers designed to be idiots. They expect a YR and then a KK.
Every new YR resets their state.
They are not responsible to check for more and must not do it.
Squid code is responsible for this, and I believe this patch does not
break anything in this area: Any expired reservation results to close
client connection.
A any new connection still have to repeat the 3 NTLM authentication
steps to authenticate.
Am I missing something?
reservation state. The victim client generates the YR, then after
timeout the attacker supplies the KK. The TT goes out on one TCP
connection, and the KK returns via a different one.
PS. also note that this is only an issue for NTLM. However the existence
of Negotiate/NTLM flavour of Negotiate makes that interface hit the same
problem at times. This whole reservation thing is irrelevant with Kerberos.
Amos
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
