Tom Lane wrote:
> [ scratches head ... ] I don't see the problem. AFAICS the "verify
> packet" code is just looking at local storage. Where is the spoofing
> possibility, and why would delaying the socket close accomplish
> anything?
Looking at local storage isn't the issue. There is no buffer overflow
or any problem related to local storage.
The issue is that the "verify packet code" treats malformed packets as
failed authentication. Since an attacker can easily send malformed
packets, he can force authentication to fail. The code then stops
looking for a *good* response, so the real "authentication succeeded"
message is ignored.
Similarly, the code checks the signature of the response, as required.
But it also treats "bad signature" as failed authentication. This is
despite the requirements of RFC 2865 Section 4.2 (among others):
... The Response Authenticator field
MUST contain the correct response for the pending Access-Request.
Invalid packets are silently discarded.
i.e. the invalid packet should be ignored, and the socket left open,
so that it can continue to look for the *good* response.
I've attached a set of patches which gradually re-arrange the code so
that it ignores invalid packets, and keeps trying to read a "good"
response until the timer expires. I've also changed the messages saying
"bad packet" from 'errors' to 'warnings'. Being attacked isn't an error. :)
Alan DeKok.
