Re: Possible fix for Kaminsky's bug
At Wed, 27 Aug 2008 11:02:27 -0400,
"L. Gabriel Somlo" <email@example.com> wrote:
> > I'm pretty sure that this patch doesn't avoid all variations of
> > Kaminsky's attack,[/color]
> Hehe... I never claimed my one-character patch would fix *all* bugs
> in bind -- I don't have *that* kind of power ;)[/color]
Okay, but this point is important because whether or not a "fix" is
complete can be critical in assessing the value of the fix (see
below), and this is indeed critical in our case. So I wanted to be
sure about that point.
> Allright, here's the long version:[/color]
Thanks for the detailed explanation. This is exactly what I expected
this change tries to avoid.
Now, going back to your question:
> What's the downside to my patch ?[/color]
It has an obvious downside: the server will then fail to catch a real
change of NS (made by the legitimate administrator) in a timely
fashion even if it has an opportunity for that in an updated response.
One may want to argue that this drawback is minor compared with the
improved security. This might be true if it fixed all (or at least
the vast majority) of the wide variations of "Kaminsky attack" (see
above). The fact is, it doesn't. For example, this type of counter
cannot avoid the following attack...
- the attacker forces the recursive server to query for
- the attacker also sends the following forged responses:
authority: [url]www.cnn.com[/url]. NS evil.net.cmu.edu.
additional: evil.net.cmu.edu. AAAA 2001:db8::bad
....unless the recursive server has already cached some
[url]www.cnn.com./NS[/url], which cannot normally be expected to be the case for
names like [url]www.cnn.com[/url]. Even though this attack only steals a single
name (unlike stealing the whole 'cnn.com' domain), this should be more
than sufficient for criminal in reality, since such subsets of domain
names are the ones they would actually want to control.
Of course, if the recursive server has cached a valid [url]www.cnn.com/A[/url],
the result of the attack won't be effective until it expires. But
once it expires, the attacker gets the full control of it and keeps
the situation as long as they want. (This is different from how the
TTL matters in the traditional brute force attacks).
This attack is as easy and powerful as your scenario, and cannot be
avoided by the proposed patch. Since the patched server would soon be
attacked in the other way, I don't see a strong reason for adopting it
despite its drawback.
Commenting on your other points:
> The attacker has the "starter pistol" to the "race", because whenever they
> do manage to slip victim.net.cmu.edu a spoofed reply, the NS record for
> cnn.com gets overwritten, and the attacker wins. They can try as often as
> they want, and the more they try, the better their chances of winning.[/color]
This is correct.
> With my patch applied, the tie between equal dns_trust_authauthority values
> of the cached NS record and the new (fake) one is broken in favor of the
> cached one, and the attacker is back to where they used to be before
> Kaminsky's exploit, which means they have to wait and guess right during the
> short window of opportunity when the cache expires, and if they get it wrong,
> they have to wait for the next time the TTL runs out.[/color]
This is also correct, *for the limited variation of Kaminsky's attack*.
> I believe this was the source of the entire hoopla about Dan's exploit, the
> fact that timing of the attack was now under the control of the attacker.[/color]
This is only half-true. The most essential point is that once the
attacker can start the attack, they can repeat it as many times as
they want. If they can additionally control the start time of the
attack, that's a plus, but it's a relatively minor point.
Internet Systems Consortium, Inc.