[conspire] DNS vulnerability details

[Rick Moen]

Hi, Ruben.  I'll just try to see if I can add anything to Ryan's
admirably concise explanation.  (I probably can't, because unfortunately 
I was obliged to work on a server emergency in the middle of the night,
and so am dead tired -- but I'll try.)

Quoting Ruben Safir (ruben at mrbrklyn.com):

> The first client resolver request sends to DNS.myserver.com on port 53

This is not the hop where the problem occurs.  Remember, as I explained, 
even to the (questionable) extent that you can flood a client resolver
library with faked responses to such requests, that doesn't buy the
attacker very much, because client resolver libraries _don't cache results_.

As Ryan said, the point of vulnerability occurs when DNS.myserver.com
receives the query (which arrives with the recursion bit set).
DNS.myserver.com consults its cache, figuratively shrugs "Dunno",
notices the recursive bit set, and sends the query _onwards_ to somewhere 
-- some additional nameserver, say, DNS.other.com -- that will
eventually result in a response being forwarded back, the requested RR
whose attached TTL value still has some life in it.

When DNS.myserver.com lobs its outbound copy of the original client's
request, if it's a dumb, _tradition_-style nameserver, it will use some
highly predictable source port, e.g., locked to port 53.  All BIND8,
BIND9 before the current P1 patches, pdnsd, dnsmasq (used in _many_
embedded appliances!), and Microsoft Windows DNS Server all do the dumb
thing.  PowerDNS, Dan Bernstein's dnscache (part of djbdns), Unbound,
and MaraDNS do not:  Those all originate the second-hop request from a
properly randomised source port.

There are several obvious ways to induce the original DNS client (the
one that handed off the request to DNS.myserver.com) to ask about a
domain that's firmly under the control of the bad guys, e.g., embedding
references to that domain in Web pages that users of the original client
machine then are induced to browse.  Let's say that domain is
evilco.com.  

1.  Original DNS client asks DNS.myserver.com "Where's images.evilco.com?"
2.  DNS.myserver.com doesn't know, sends outbound query onwards to 
    DNS.other.com.

At the same time, the evilco.com guys, alerted to the outbound query to
evilco.com's Web site, start flooding DNS.myserver.com's LAN with forged
DNS-response packets that purport to be from DNS.other.com, with a
variety of QID (transaction ID) numbers, attempting to race back to
DNS.myserver.com before the genuine response from DNS.other.com does.
The forged response contains a perfectly serviceable response to the
"Where's images.evilco.com?" question, but also bears data in the
"ADDITIONAL SECTION" portion designed to lodge in DNS.myserver.com's
cache, concerning some other domain entirely.

With only 65536 possible QIDs, evilco.com has a good chance of
succeeding.  If DNS.myserver.com's query came from a fixed port, then 
that's all evilco.com need do.  OTOH, if DNS.myserver.com has also sent
the query from a randomly selected source port (on which the reply must
also arrive), then that makes it a significantly more difficult target.

> I can't help but feel that until of criticle systems services are
> using cryptography, that we just continue to go in circles.

There's a saying about crypto not making very good magic pixie dust.