Possible fix for Kaminsky's bug

[L. Gabriel Somlo]

On Fri, Aug 29, 2008 at 11:33:07PM -0700, JINMEI Tatuya wrote:
> > What's the downside to my patch ?
> 
> 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.

You trade slower convergence of the global state of DNS for decreased
vulnerability of each individual cache out there. That much was always
on the table...

> - the attacker forces the recursive server to query for
>   86ANDC8zkC8.www.cnn.com/A
> - the attacker also sends the following forged responses:
>   question: 86ANDC8zkC8.www.cnn.com/A
>   answer: (empty)
>   authority: www.cnn.com. NS evil.net.cmu.edu.
>   additional: evil.net.cmu.edu. AAAA 2001:db8::bad
> 
> ...unless the recursive server has already cached some
> www.cnn.com./NS, which cannot normally be expected to be the case for
> names like www.cnn.com.  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 www.cnn.com/A,
> 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).

I tried that, and it doesn't work if the victim server already has an
A record for www.cnn.com cached. The attack you described relies on
there being nothing in the cache for www.cnn.com. The presence of an A
record means the attack must succeed before the valid A record gets
cached or wait until after it expires and before it gets renewed again.

The other variation on Dan's attack (which is to return host A records
in the additional section of a spoofed reply) also only works when the
cache doesn't already contain an A record.

I thought I was pretty clear on the scope of my patch: I'm trying to
limit hackability to records not already in the cache, or to the interval
between TTL expiration and cache refresh. Combining this with the
new-and-improved source port randomization should make everything safe
enough to allow the migration to DNSSec to proceed on its own merits,
rather than mandated by panic over the hype caused by Dan's exploit.

> 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.

Not sure it's equally powerful, unless there's a way to make it work
whenever (and however often) an attacker chooses. If the attacker is
constrained to only poisoning records that aren't already cached, or
having to wait for an existing record's TTL to expire, we're mostly
back to the state we were in before Dan figured out his exploit.

Dismissing this patch from consideration (or something similar to it,
obviously left at the discretion of the caching server's operators as
a config option), sounds a lot like refusing to wear a flak jacket
against bullets because you might always just get kicked in the groin
instead :)

> Commenting on your other points:
> 
> > 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.
>
> 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.

If we remove control of the attack's timing from the attacker, it
becomes a self-correcting problem. The more prominent the record being
spoofed, the more likely is that it will stay cached by the target
server due to demand from clients. You may be able to sit there and
quietly "poison" my cache with www.whocares.org, which is unlikely to
be in the cache because, well, nobody cares. However, www.cnn.com will
keep refreshing regularly (most likely from the real authority NS of
cnn.com) due to popular demand.

Thanks,
Gabriel