[squid-dev] [PATCH] Reuse reserved Negotiate and NTLM helpers after an idle timeout.
christos at chtsanti.net
Tue Aug 8 15:18:16 UTC 2017
Στις 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
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.
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
More information about the squid-dev