[TAG] (forw) Re: [conspire] DNS vulnerability details
Rick Moen
rick at linuxmafia.com
Tue Aug 5 00:48:46 MSD 2008
Eric's situation is actually fairly typical for SOHO Linux users,
except that he's ahead of the curve in (1) being aware of the problems
and (2) actually bothering to run a good security-oriented Linux
distribution on his Linksys box. However, I notice that even _he_
ignored my advice to run and use a local caching recursive-resolver
nameserver.
"Outsource everything to OpenDNS" is _not_ semantically equivalent to
"run and use a local caching recursive-resolver nameserver", folks.
----- Forwarded message from Eric De MUND <ead-conspire at ixian.com> -----
Date: Sun, 3 Aug 2008 17:58:19 -0700
To: conspire at linuxmafia.com
From: Eric De MUND <ead-conspire at ixian.com>
To: TAG <tag at lists.linuxgazette.net>
Reply-To: Eric De MUND <ead at ixian.com>
Subject: Re: [conspire] DNS vulnerability details
Hello,
Ok, I believe I've completed phase 1 of 2 of eliminating my DNS vul-
nerability, that of fixing my SOHO network. Phase 2 will be to patch
my debian laptop which travels out into the world. 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?
Here at home, in phase 1:
a. I upgraded the firmware of my Linksys WRT54G v2.2 router to
"DD-WRT v24-sp1 (07/27/08) std". Though dd-wrt.com noted in [1],
"We'd like to make clear that the DD-WRT default configuration in
v23 / v24 is not vulnerable, so there was and is no risk for dd-wrt
users," their list of overall enhancements for v24 sp1 included, on
the very first line:
o DNS security fix for dnsmasq
b. I configured my router thus (">>" indicates a change, "[v]"
indicates a check in a checkbox):
Router IP
Local IP Address 10.0.0.1
Subnet Mask 255.255.255.0
Gateway 10.0.0.1
>> Local DNS 208.67.222.222 # resolver1.opendns.com
Network Address Server Settings (DHCP)
DHCP Type DHCP Server
DHCP Server (o) Enable ( ) Disable
Start IP Address 10.0.0.100
Maximum DHCP Users 50
Client Lease Time 1440 minutes
>> Static DNS 1 208.67.222.222 # resolver1.opendns.com
>> Static DNS 2 208.67.220.220 # resolver2.opendns.com
Static DNS 3 0.0.0.0
WINS 0.0.0.0
>> Use DNSMasq for DHCP [v] # these checkboxes might have
>> Use DNSMasq for DNS [v] # been selected previously; I
DHCP-Authoritative [v] # can't recall
c. I did not install BIND on any of the systems behind my router.
(Yes, a la Monty Python, "There is no step c.")
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.
So, to inquire again, why am I not done with phase 1? Why might I need
to install BIND on a system behind my router?
Thanks a million,
Eric
links:
1. DD-WRT v24 SP1
http://www.dd-wrt.com/dd-wrtv3/community/developmentnews/1-common/24-dd-wrtv24sp1.html
--
"The ship be sinking."
"How far could it sink?"
"Sky's the limit."
--reporter in conversation with pro basketball player
Micheal [sic] Ray Richardson, on the New York Knicks
Eric De MUND | Ixian Systems | Jab: eadixian at jabber.org/main
ead at ixian.com | 650 Castro St, #120-210 | Y!M: ead0002
ixian.com/ead/ | Mountain View, CA 94041 | ICQ: 811788
_______________________________________________
conspire mailing list
conspire at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
Date: Mon, 4 Aug 2008 13:19:15 -0700
From: Rick Moen <rick at linuxmafia.com>
To: TAG <tag at lists.linuxgazette.net>
To: conspire at linuxmafia.com
Subject: Re: [conspire] DNS vulnerability details
(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.
_______________________________________________
conspire mailing list
conspire at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
More information about the TAG
mailing list