Would you trust *.com DNS information from a computer that's running
BIND 8.2.1 and Sendmail 8.8.5 today, sitting on an open network in the
electrical engineering department at a large Australian university?
``Of course not,'' you say. ``Top-level DNS servers can't use versions
of BIND with well-known remote root exploits. They can't run any mail
programs. They can't be on open networks. They have to be protected from
sniffing. This is how the twelve official .com servers are run.''
But there's a difference between the twelve official .com servers and
what your DNS cache _thinks_ are the .com servers. This is true even if
all IP packets are cryptographically authenticated.
Suppose an attacker can make recursive queries through your cache. Let
me emphasize that this does not mean that the attacker is one of your
beloved users; many programs act as DNS query-tunneling tools.
Suppose the attacker is also able, somehow, to take over ns2.netsol.com.
This isn't one of the .com servers, but it's a name server for the
gtld-servers.net domain. Here's what happens:
(1) The attacker asks your cache about z.com. Your cache contacts
(say) k.root-servers.net, which provides a referral:
com NS j.gtld-servers.net (among others)
j.gtld-servers.net A 198.41.0.21
These records are cached.
(2) The attacker asks your cache about z.gtld-servers.net. Your cache
contacts (say) f.root-servers.net, which provides a referral:
gtld-servers.net NS ns2.netsol.com (among others)
ns2.netsol.com A 207.159.77.19
These records are cached.
(3) The attacker takes over ns2.netsol.com.
(4) The attacker asks your cache about zz.gtld-servers.net. Your
cache contacts ns2.netsol.com, and the attacker answers:
zz.gtld-servers.net CNAME j.gtld-servers.net
j.gtld-servers.net A 1.2.3.4
These records are cached, wiping out the obsolete j glue.
(5) A legitimate user asks your cache about yahoo.com. Your cache
contacts j.gtld-servers.net, and the attacker answers:
yahoo.com A 1.2.3.4
The user contacts yahoo.com at that address.
In some of these steps, your cache could have tried other servers first.
Perhaps the attacker briefly flooded your network, or those servers. Or
perhaps the attacker abused BIND's bogus ``credibility'' rules, as I
described in a previous message, to knock the other server addresses out
of your cache.
Of course, the same pattern can be extended. The attacker can start by
taking over one obscure computer in Australia. That lets him control the
address of a slightly less obscure computer; this power, in turn, lets
him control the address of yet another computer; and so on. After a
chain of ten NS records, he controls .com. (Exercise: Find this
computer. Hint: The chain doesn't include ns2.netsol.com.)
Right now there are more than 200 computers, spanning 224 IP addresses,
that can trivially take over .com in this way. They don't have to forge
packets; their power is provided by the architecture and configuration
of the Domain Name System. Some of these computers are clearly insecure.
Similar comments apply to many second-level domains that use third-party
slave servers. If your.dom has an NS record of fud.third.dom, you're
trusting not only the real fud.third.dom machine, but all the third.dom
servers. It's better to copy the real IP address to b.ns.your.dom, and
use that in your NS record. This also improves the reliability of the
resolution process:
http://cr.yp.to/dnscache/notes.html#gluelessness
The only real obstacle is NSI, which currently doesn't allow
registration of multiple names with the same IP address.
---Dan
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:30:34 PDT