At Thu, 21 Aug 2008 15:12:07 -0700,
JINMEI Tatuya wrote:

> > > - the recursive server replaces the forged NS RRset with the
> > > legitimate one:
> > > . IN NS [a-m].root-servers.net.

> >
> > Well, you could do that - hardcode the list of root-servers. Is that what
> > people do?

>
> Oops, I meant:
>
> - the recursive server replaces the legitimate NS RRset for .
> (which is normally) . IN NS [a-m].root-servers.net.
> with the forged NS RRset
>
> Is this what you had in your mind?


I've been hoping someone enlightens me, but there seems to be no luck.
So I'll continue speculating...

I've missed "answers" in the example given before:

: Send queries for '1.', '2.', '3.', '4.' etc to a resolver. In the meantime,
: blast it with answers for '1.', '2.' etc with new NS records of your choosing
: for '.'. Be sure to pick the source address of the nearest root-server.

so the intent is perhaps this one:

- the attacker (somehow) force the recursive server to send a query
for (e.g.) '1. IN AAAA'
- then the attacker sends a forged response as follows:
question: 1. IN AAAA
answer 1. IN AAAA 2001:db8::1234
authority: . IN NS evil.example.
additional: evil.example. AAAA 2001:db8::1
- the recursive server replaces the legitimate NS RRset for .
(which is normally) . IN NS [a-m].root-servers.net.
with the forged NS RRset, possibly with the additional AAAA RRset

(Un)fortunately, this attack succeeds only in a very limited situation
as long as the recursive server performs "priming" (as described in
draft-koch-dnsop-resolver-priming-00) and follows the data ranking
concept described in Section 5.4.1 of RFC2181: the recursive server
should have a cached entry of "./NS" at the data rank of "The
authoritative data included in the answer section of an authoritative
reply" as a result of priming, while the rank of the forged authority
section is "Data from the authority section of an authoritative
answer". So, the forged response cannot unconditionally replace the
existing cache. This is one major difference for "." from any other
domains.

The attacker could wait for the expiration of the high-rank cache;
however, the first query (which may or may not be caused by the
attacker) after the expiration will immediately trigger the next
priming and the high-rank data is soon cached again, so the possible
attackable window is very limited. This is another major difference
for "." (+ the notion of priming) from any other names in the context
of Kaminsky's attack.

Of course, this defense depends on whether implementation diligently
performs priming and follows the data ranking rule of RFC2181. One
implementation that I know very well behaves that way (I've actually
confirmed that by "attacking it" based on the above scenario); as far
as I can confirm, that's the only implementation that meets this
requirement, though.

In any event, this is probably a different attack scenario from what
you were thinking when you said this:

: 3) DNS-0x20 - although that doesn't protect the vital and scary . and COM
: records from numerical kaminsky attacks.

I'm very much interested in knowing that (if it's not secret:-).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: