[conspire] DNS vulnerability details

[Rick Moen]

(Getting back to your question from yesterday):

Quoting Eric De MUND (ead-conspire at ixian.com):

> Please educate me if I've missed anything in phase 1. In particular,
> given "GREAT" test results in step d, below, why might I still need to
> install BIND on any of the SOHO systems behind my router?
[...]
> d.  From all three systems behind the router (2 x debian 4.0r4 +
>     1 x Mac OS X 10.5.4), I ran the [Test My DNS] test at
>     <https://www.dns-oarc.net/oarc/services/dnsentropy>. All tests
>     reported:
>     DNS Resolver(s) Tested:
>     1. 208.67.219.11 (bld1.pao.opendns.com) appears to have GREAT
>     source port randomness and GREAT transaction ID randomness.

That's always nice to know, but actually has very little to do with the 
Dan Kaminsky-reported DNS nameserver vulnerability, _because_, for good
or bad, those resolver libraries are not caching recursive-resolver 
nameservers.


Although it's A Good Thing for any software that originates a recursive
query to randomise its source port, the only attack targets of
significant concern are _caching_ nameservers (that do recursive service).

o  Your Debian and MacOS boxes -- being TCP/IP-capable -- have DNS 
   resolver libraries (DNS clients).  Neither of those OSes' libraries
   is particularly competent at randomising their UDP ports on outgoing 
   DNS queries whose recursive bits are set, _but_ results received 
   back are not cached.  So, there's very little payoff to a theoretical
   attacker from sending them forged responses with cache-poisoning data 
   -- there being no cache to poison.  Get it?

   If there were a patch to fix those two OSes' resolver libraries,
   that would be A Good Thing.  The one in Linux glibc is a bit of 
   dismal code taken from <shudder> BIND8, for which, for now, there is
   no replacement.  And there's been not a peep out of Apple about
   prospects for fixing their resolver library.[1]

o  I gather that your Linksys[2] runs dnsmasq.  dnsmasq
   is a basically fairly decent DNS forwarder (and DHCPd) for small
   networks (usually behind NAT).  Fairly decent, except that the
   author (originally) fscked up the way it forwards received recursive DNS
   queries, failing to randomise the source ports.  (By comparison,
   the somewhat similar pdnsd package got that point right.)  It's 
   recently been patched, adding Dan Bernstein's "SURF" random-
   number generator, starting with v. 2.43.  (Current is 2.45.)
   
   It's important to note that dnsmasq _does_ do caching of received
   responses.  So, if an attacker were to succeed in sending it 
   forged responses with cache-poisoning data in the ADDITIONAL 
   INFORMATION section of the response, that would be a problem.
   So, the improvement in query algorithm starting with 2.43 _is_
   significant for security.  So, it's good that you applied the
   dd-wrt distro's v24 SP1 update.

   I have no idea whether dd-wrt runs dnsmasq on the outside interface 
   or the inside, NATted one.  On the outside would make more sense.

o  Queries from the two OSes' resolver libraries (DNS client pieces) have 
   to traverse your Linksys router's NAT/IP-filter layer.  At some
   point, either before or after NAT translation, they pass through
   dnsmasq.  Anyway, dd-wrt's algorithm for generating source UDP ports 
   is likely to be also security-significant.  Which raises the
   question:  How good _is_ that?  (You have no data on that question.)

   You appear to have the Linksys configured to forward all outbound
   DNS requests out to OpenDNS's public nameservers, 208.67.222.222
   and 208.67.220.220 (resolver1.opendns.com and resolver2.opendns.com).
   You applied the Web-based test of source-port randomness to 
   OpenDNS.  Wouldn't it be also relevant to test the outside IP of 
   your Linksys?


In any event, to recap:

1.  You have poor source-port randomisation on Debian and MacOS,
but that doesn't matter a great deal because they don't cache.  In an
ideal world, those OSes' shoddy DNS-client software would get junked and
replaced.  Some day.

2.  Those client libraries forward to the Linksys/dd-wrt gateway, which
at least has dnsmasq patched to do decent port randomising -- important
because it caches data.  dd-wrt v24 SP1's _own_ port randomising quality
is unknown and untested.

And the Linneus Bottomus:

3.  You've outsourced all your (non-cached) DNS queries to OpenDNS.
(That is, your installation of dnsmasq has that San Francisco firm's two
public IPs specified as its forwarders.)


Personally, I would _not_ outsource my DNS.  To anyone.  I would (and
do) run my own caching recursive-resolver nameserver.  dnsmasq does not
qualify because _it_ does no recursive service:  It merely forwards all
such queries to an IP you specify.

And, no, I would not (for new installations) run BIND9[3].  I wish people
would stop thinking of BIND as synonymous with nameservers.  Even BIND9,
which ended the perennial security nightmares of BIND8, is a slow,
bloated, overfeatured, monolithic piece of garbage.  There are much more
suitable, tailored, alternatives.  (See prior e-mail.)


To expand on one of several reasons I would avoid OpenDNS:  They break
the RFC-mandated requirement to return NXDOMAIN (no such domain) on
non-existent FQDNs[4].  Notice what happens when one asks a _reasonable_
nameserver (mine) about a non-existent domain:


:r! dig i-dont-exist.com @ns1.linuxmafia.com

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24606
                                       ^^^^^^^^
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1217879779 1800 900 604800 900



Note underlined "status" return value.  (It's "NXDOMAIN" = Non-eXistent
DOMAIN", get it?)

Now, compare what one gets from OpenDNS:

:r! dig i-dont-exist.com @resolver1.opendns.com


;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34753
                                       ^^^^^^^
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
^^^^^^^^^^^^^^^^^^
i-dont-exist.com.	0	IN	A	208.67.219.132
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


The return values are the NOERROR result code and (the actual response)
IP address 208.67.219.132. 

How can this be?  It doesn't actually exist, so shouldn't the correct
response be NXDOMAIN?  Yes, but OpenDNS's business model requires that
they break the RFCs.  

Why 208.67.219.132?  Because that's where they've put up a Web server
that returns advertising, on any DNS lookup that _would_ otherwise
return NXDOMAIN.

This is of course exactly what we all beat up Verisign over (the 
"Sitefinder" fiasco) -- with the distinction that, in OpenDNS's case,
nobody's being forced to use lobotomised DNS:  You have to volunteer for
it by pointing your queries it their nameservers, deliberately.



The alternative is, of course, to run a local caching recursive-resolver
nameserver.  I've already suggested that, and you've thus far elected 
not to do it.  It would avoid breaking the RFCs for no better reason
than feeding OpenDNS's business model, it would give you better 
performance, it would avoid massive privacy loss, and it would 
put your DNS and its security under _your_ control instead of OpenDNS's.



[1] However, Apple rolled out the July 8 BIND9 "P1" patches into one of 
their omnibus security updates, a few days ago.  (Most MacOS users 
do not elect to enable BIND9, so this doesn't make a difference to most
MacOS users' security, and does nothing about the client resolver
library, but it does show that Apple are fairly on top of the recent
security problem.)

In fairness, there would _not_ be a peep out of Apple about prospects
for replacing the OS X DNS resolver library, even if it were due out 
this afternoon, because they do not comment about upcoming software,
including security updates, until release time.

[2] Because you really weren't very clear on this, at first reading I 
assumed that you meant one of your _Debian_ boxes was running dnsmasq,
rather than the Linksys.

[3] I do currently run BIND9, for both recursive-resolver caching
service and for authoritative service.  I would not select it for either
role, in any new installations.  NSD is an absolutely superb
authoritative server.  I'm not sure which way I'd jump for the
recursive-resolver caching portion:  I'd consider Unbound, PowerDNS
Recursor, the non-authoritative portion of MaraDNS, _and_ even DJB's 
dnscache.  I have high hopes for Unbound, as it's from the NSD people
-- but it's brand-new.

[4] Fully-qualified domain names.