[conspire] DNS vulnerability details

[Rick Moen]

Let me expand on that, particularly for the benefit of the majority of
you who do _not_ run your own DNS nameservers -- because everyone has a
horse in this race, not just sysadmins:

When your app (say, a Web browser or e-mail client) needs to communicate
with a remote host, it invokes the system DNS service.  On Linux boxes, 
that's a small library (disturbingly, derived from horrible, ancient,
BIND8 spaghetti code) built into the system C library called the
resolver.  The resolver, which is each TCP/IP system's DNS _client_
piece, has (on Linux) /etc/resolv.conf as its configuration file.

For the 98% of you who get your IP address, nameservice details,
routing, and so on via DHCP, that file gets overwritten frequently, each
time your DHCP lease is renewed, FYI.  Please do have a look at your
/etc/resolv.conf.  It's really simple.  My server's own resolv.conf:


search linuxmafia.com deirdre.org
nameserver 198.144.192.2
nameserver 198.144.192.4
nameserver 198.144.195.186


The first line says "If the silly human gives a less-than-fully-specified 
hostname, try 'linuxmafia.com' as the domain suffix, and then also
'deirdre.org', before giving up."  The remaining three lines give the IPs
of three DNS _servers_ where the resolver client can deliver queries.
The first two are (excellently run!) nameservers at my upstream link,
Raw Bandwidth Communications.  The third is my own nameserver.

You folks on DHCP get all such lines from your DHCP server.  (There are
also ways to configure your DHCP client to modify this behaviour.)  
If you control your own DHCP server, e.g., as part of a "firewall" 
appliance, then you can determine what configuration data gets passed
out with the DHCP IP leases.

Anyhow, your resolver library lobs a query off to one of the DNS nameservers
listed in resolv.conf.  What does the nameserver do?  It's like asking a
research librarian:  Either he/she knows, or knows whom to ask.
"Knowing" is the model called authoritative DNS service:  That's where
your query happens to go to one of the nameservers that are the
recognised, worldwide authorities for what DNS data that domain is
serving at this moment.  "Knowing whom to ask" is called
recursive-resolver service, where your query reaches a nameserver that
is not authoritative for the queried domain, but happens to have the
requested data in its cache of data that others have asked for in the
recent past ("I know a guy, who knows a guy...."), and that the
accompanying "use by date" stamp (the "time to live" value) suggests
that data are still good.  

It's been known for a long, long time that recursive-resolver service is
technically difficult, and has huge security pitfalls.  Among the worst
hazards is a malicious party "poisoning" the cache data of a
recursive-resolver server your local resolver library queries.  Such
caches can be poisoned only via queries from resolvers (DNS clients)
on the servers' lists of IPs permitted to send them recursive queries.
Remember when you signed up with your ISP and they gave you a small list
of IPs that you can use as nameservers?  (Maybe you don't, because
you're using 100% DHCP.  In that case, you're getting those IPs with
your lease.)  Those are nameservers your ISP is exposing to a huge
number of users for recursive service -- at miminum, all of its
customers, and some ISPs leave their public nameservers open to
recursive queries from anywhere at all. 

So, lesson #1:  One of the easiest ways to reduce your security exposure
to _all_ DNS security issues is to avoid using (most) ISP nameservers
for your general DNS needs.  You can do that by setting up your own
recursive-resolver nameserver package.  The thing hardly anyone knows
_except_ sysadmins is that doing so is dead-simple.  You pretty much
just install the package and it works great by default.  No tweaking, no
futzing around.  You just have to make sure resolv.conf points to it.
It costs you a bit of RAM, and that's about it.  Anyone can and should
consider doing that -- yes, even on laptops.

Basically, ISP nameservers are (in general) Typhoid Marys.  Don't use
them!  The fact that I'm still relying in part on Raw Bandwidth's
reflects the high esteem in which I hold Mike Durkin's operation, there,
but that does NOT generalise to other ISPs.


A lot of people including Dan Bernstein pointed out, starting many years
ago, that recursive queries are dangerously easy to forge (I mean, to
forge a faked response loaded with bogus data that is then accepted as
having come from the real nameserver the resolver actually asked).
Recursive queries have a (sort of) unique transaction ID number, called
a query ID (QID) -- but that's just a 16-bit number, which is rather too
few, making forged responses much more likely to succeed than if QIDs
were, say, 32-bit integers.

Since it's not practical to switch to longer QIDs, the only other
logical way to make it more difficult to convincingly forge responses to
recursive queries is to make the queries originate on a random TCP or
UDP port, rather than the standard DNS port 53.  Guess what?  Most
nameservers prior to the patches released on July 8, 2008 did the very,
very dumb thing, and always sent out their queries from port 53.  The
nameserver you use today probably does, too.  That's very, very bad,
because, as the "Matasano Chargen" guy and German mathematician Halvar Flake 
(http://addxorrol.blogspot.com/2008/07/on-dans-request-for-no-speculation.html)
have pointed out, the bad guys have recently figured out -- or are right
about to figure out -- how to easily poison the caches of vulnerable
recursive-resolver nameservers.  And nothing increases that
vulnerability as much as always sending out recursive queries from the
same port.

(The Matasano Chargen piece also talks about a second part of the problem:
nameservers willing to accept "out of bailwick" recursive response data:  
extra "oh, by the way" data thrown in along with the requested response
that is about a different domain entirely.  Fortunately, most modern
nameservers are pretty good about that, and it's not addressed by the
July 8 patches.)


Something a lot of people don't think much about is that your libc DNS
code is a "stub" (limited) recursive-resolver of a sort:  It originates
DNS queries with the recursive bit set, which is the "if you don't know,
please ask some other nameserver that does" signal.  Aren't they also
potentially attackable by the sort of forgery that the Matasano Chargen
guy discusses?  Yes, but "stub" resolvers don't cache their received
data, so it's not much of a threat.  (The "poison" gets flushed
immediately.)  Oddly enough, the desktop software components aren't the
problem, this time.  It's the working nameservers out on people's
(and ISPs') server machines.

And people's "firewall" boxes are going to be a _big_ problem.  Two
reasons:

1.  Many firewall appliances have built-in recursive-resolver
nameservers.  Guess how many of those are likely to get patched?  Right,
almost none.  (Fortunately, probably most of them are non-caching.)

2.  Let's say you follow my advice and run a caching nameserver on your
local machine -- and that you operate behind a "firewall" gateway
appliance that connects your DSL or cable link to upstream, and that
does NAT / port address translation (as they pretty much all do) so you
can get by with a single IP.  You're wary and so patch your systems to
get the July 8 patches -- so that your resolver is originating its
queries from a random port, instead of always sending them from port 53.  

Good, right?  Except, then, the firewall appliance's network address
translation / port address translation (NAT/PAT) algorithm kicks in, and
rewrites the outbound traffic.  The originating port was random, so the
firewall's rewritten version of that same packet should likewise have a
random source port, right?  Because all $40 cheap plastic appliances
have excellent random number generators, right?  Oops.  Sorry, your
originating port assignment probably doesn't end up being quite so
random, any more.  See:
http://www.circleid.com/posts/87143_dns_not_a_guessing_game/  Basically,
a typical firewall box makes a rather efficient de-randomiser.



Testing your nameserver's randomness of source port selection:

Do:
$  dig [namserver IP or hostname] porttest.dns-oarc.net in txt

The result string will include a editorial comment like "GOOD", "FAIR",
or "POOR" about randomness quality.

Or use this Web facility:
https://www.dns-oarc.net/oarc/services/dnsentropy


You really do want to attend to this now.  It's not Somebody Else's
Problem.