...making Linux just a little more fun!
Rick Moen [rick at linuxmafia.com]
----- Forwarded message from Eric De MUND <[email protected]> -----
Date: Wed, 23 Jul 2008 22:37:55 -0700 To: [email protected]X-Mailer: VM 7.19 under Emacs 21.4.1
From: Eric De MUND <[email protected]> Reply-To: Eric De MUND <[email protected]> Subject: Re: [conspire] DNS vulnerability detailsRick,
First of all, a huge thank you for posting this very clearly written report /with prescription/. I'm an expert in some tiny little areas, and DNS isn't one of them. This is useful to me in quickly getting from poor safety maybe not to excellent safety but perhaps to "pretty good" safety.
I appreciate the sharing tremendously. Rick, you are a guy.
] Testing your nameserver's randomness of source port selection: ] ] Or use this Web facility: ] https://www.dns-oarc.net/oarc/services/dnsentropy
Ok, in repeated tests, I'm getting 2/3 POORs and 1/3 GOODs for source port randomness, and all GREATs for transaction IDs. This is Comcast.
DNS Resolver(s) Tested:
1. 68.87.76.179 (sjos-cns01.sanjose.ca.sanfran.comcast.net)
appears to have POOR source port randomness and GREAT transaction
ID randomness.
2. 68.87.76.181 (sjos-cns03.sanjose.ca.sanfran.comcast.net)
appears to have POOR source port randomness and GREAT transaction
ID randomness.
3. 68.87.78.131 (utah-cns01.saltlakecity.ut.utah.comcast.net)
appears to have GOOD source port randomness and GREAT transaction
ID randomness.
So what DNS-related debian package(s) do I need to get and run?
Regarding my Linksys WRT54G broadband router which is running DD-WRT v23 SP2 (09/15/06) std firmware, I think that if a patch is required, one will be made available shortly.
Regards, Eric
-- Eric De MUND | Ixian Systems | Jab: [email protected]/main [email protected] | 650 Castro St, #120-210 | Y!M: ead0002 ixian.com/ead/ | Mountain View, CA 94041 | ICQ: 811788http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message ----- ----- Forwarded message from Rick Moen <[email protected]> -----
Date: Thu, 24 Jul 2008 09:20:00 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: Re: [conspire] DNS vulnerability detailsQuoting Eric De MUND ([email protected]):
> Ok, in repeated tests, I'm getting 2/3 POORs and 1/3 GOODs for source > port randomness, and all GREATs for transaction IDs. This is Comcast. > > DNS Resolver(s) Tested:
Please don't read this as a complaint, but rather as a caution about terminology: Most people reserve the term "DNS resolver" to refer only to the DNS client piece (the one that on Linux is built into libc and has conffile /etc/resolv.conf). Being careful about terminology can help avoid confusing one's self.
> 1. 68.87.76.179 (sjos-cns01.sanjose.ca.sanfran.comcast.net) > appears to have POOR source port randomness and GREAT transaction > ID randomness. > > 2. 68.87.76.181 (sjos-cns03.sanjose.ca.sanfran.comcast.net) > appears to have POOR source port randomness and GREAT transaction > ID randomness. > > 3. 68.87.78.131 (utah-cns01.saltlakecity.ut.utah.comcast.net) > appears to have GOOD source port randomness and GREAT transaction > ID randomness.
As I said, ISP nameservers in general really suck. I'm not at all surprised that Comcast isn't on the ball.
> So what DNS-related debian package(s) do I need to get and run?
On Debian, just "bind" (http://packages.debian.org/etch/bind). You can optionally grab "bind-doc" if you want a whole lot of informative stuff that you'll probably never read put into /usr/share/doc/bind-doc/ . ;->
Debian constructs a quite reasonable default /etc/bind/named.conf file (BIND9's configuration file), in such a way that hardly anyone needs to touch it -- because it references as "include" files two others that local admins can put all their local configuration in:
/etc/bind/named.conf.options : This is where you put things like what
IPs are permitted to query the nameserver
for various sorts of nameservice.
/etc/bind/named.conf.local : This is where you'd put stuff related
to zones for which you want BIND9 to do
authoritative service, e.g., if you felt
like registering ericdemund.com and doing
its authoritative DNS from your home
machine.
Here is my own (BIND9) nameserver's /etc/bind/named.conf.options :
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
version "Shirley, you're joking";
forwarders {
198.144.192.2;
198.144.192.4;
// 209.81.9.1;
// 165.90.49.12;
};
auth-nxdomain no; # conform to RFC1035
allow-recursion {
127.0.0.0/8;
192.168.0.0/24;
10.0.0.0/8;
198.144.195.186/29;
};
allow-query {
127.0.0.0/8;
192.168.0.0/24;
10.0.0.0/8;
198.144.195.186/29;
};
};
logging {
category lame-servers {null; };
};
One important thing to note is the "allow-recursion" and "allow-query" rosters: Those are (respectively) the ranges of IP addresses permitted to send recursive-resolvers queries, and those permitted to send it queries of any sort.
Also, note the commented-out "query-source address * port 53;" statement. This is where you can _deliberately lock_ your nameserver to originate queries from a specific port address -- which we've known for many years is an extremely bad idea. (The asterisk is where you could specify which of your machine's IP addresses the queries should say they come from, in the case of a machine with multiple IPs.)
People upgrading their existing BIND9 nameservers for the July 8 patches need to check manually to ensure that such a line hasn't been activated -- because its presence negates the benefit of the upgrade (which adds support for randomised source ports!).
The BIND near-monopoly has been rather bad for DNS, over the years, so I've kept an eye on alternative nameservers for a long time, here: "DNS Servers" on http://linuxmafia.com/kb/Network_Other/ .
One of the things the world really needs is a bulletproof, easy-to-use recursive-resolver nameserver that does only that. (The BIND near-monopoly has gotten people lulled into thinking that DNS service is all one big, homogeneous thing, which it is not.) Dan Bernstein's "dnscache" (one component of the djbdns suite) qualifies in some ways, except it's rather peculiarly designed, and I suspect it's novice-hostile.
MaraDNS might qualify, but is untested by this reporter. Nick Moffitt tried it some years ago, and didn't have a good experience.
"Unbound" is extremely promising, and I have high confidence in its authors, but is absolutely brand new, and again I've not tested it at all.
_____________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
Kapil Hari Paranjape [kapil at imsc.res.in]
Dear Rick,
On Thu, 24 Jul 2008, Rick Moen wrote:
> > So what DNS-related debian package(s) do I need to get and run? > > On Debian, just "bind" (http://packages.debian.org/etch/bind).
Unfortunately, "etch" still has version 8! So that should be
http://packages.debian.org/etch/bind9
Regards,
Kapil. --
René Pfeiffer [lynx at luchs.at]
On Jul 25, 2008 at 0556 +0530, Kapil Hari Paranjape appeared and said:
> Dear Rick, >=20 > On Thu, 24 Jul 2008, Rick Moen wrote: > > > So what DNS-related debian package(s) do I need to get and run? > >=20 > > On Debian, just "bind" (http://packages.debian.org/etch/bind). >=20 > Unfortunately, "etch" still has version 8! So that should be >=20 > http://packages.debian.org/etch/bind9
But an "aptitude search bind" shows me:
p bind9 - Internet Domain Name Server=20
So you can use this package (this is what I usually do).
Best, René.
Rick Moen [rick at linuxmafia.com]
Quoting René Pfeiffer ([email protected]):
> But an "aptitude search bind" shows me: > > p bind9 - Internet Domain Name Server > > So you can use this package (this is what I usually do).
I haven't actually had anything to do with the Debian "stable" branch in many years, so I hadn't actually looked at any of those pages, only called one of them up and lazily pasted its URL into mail. ;->
Rick Moen [rick at linuxmafia.com]
----- Forwarded message from Rick Moen <[email protected]> -----
Date: Thu, 24 Jul 2008 11:20:27 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: Re: [conspire] DNS vulnerability detailsJust a further comment (on a detail of BIND9 configuration):
> Also, note the commented-out "query-source address * port 53;" > statement. This is where you can _deliberately lock_ your nameserver to > originate queries from a specific port address -- which we've known for > many years is an extremely bad idea. (The asterisk is where you could > specify which of your machine's IP addresses the queries should say they > come from, in the case of a machine with multiple IPs.) > > People upgrading their existing BIND9 nameservers for the July 8 patches > need to check manually to ensure that such a line hasn't been activated > -- because its presence negates the benefit of the upgrade (which adds > support for randomised source ports!).
To be fair, the real reason for that line's existence is IP/port filters ("firewalls"). Let's say you operate a nameserver inside a network's security perimeter (as opposed to living on your outside network, fully exposed to the Internet). Let's say you have carefully built a set of filter rules, on your outside router box, specifying what traffic is permitted in and out.
You'd probably be very tempted to lock down your (internally located) DNS nameserver's operation so that its own outbound queries always originate on TCP or UDP port 53 (DNS), because then you can put in place a firewall rule that says "permit outbound packets from host ns1 that have source port 53", and not be obliged to permit traffic originating from any and all originating ports. That is the purpose for which the "query-source" directive exists.
Again, this situation might even apply to you with your little Netgear / LinkSys / whatever "router" box connected to aDSL, cable, or dial-up service: You might have some firewall rulesets needing review.
I suspect a whole lot of sites are soon going to fall victim to one of two related pitfalls:
1. You apply the July 8 patches and restart your nameserver. You breathe a gusty sigh of relief, in the knowledge that your now-upgraded nameserver now supports random source ports on recursive-resolver queries -- forgetting entirely about the "query-source address * port 53;" line in /etc/bind/named.conf[.whatever] that prevents it from using that new ability. Your nameserver is reachable and upgraded, but remains vulnerable for reasons invisible to you, plus you now suffer from a false feeling of confidence.
2. You apply the July 8 patches and restart your nameserver, and remember to verify that no "query-source..." directive has disabled its new abilities -- but forget entirely about the firewall script blocking all traffic from that host unless it originates on port 53. Your nameserver is now upgraded and has much better security, but for reasons invisible to you is now unreachable from public networks.
_____________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
Rick Moen [rick at linuxmafia.com]
----- Forwarded message from Ruben Safir <[email protected]> -----
Date: Fri, 25 Jul 2008 18:59:55 -0400 From: Ruben Safir <[email protected]> To: Rick Moen <[email protected]> Cc: [email protected] Subject: Re: [conspire] DNS vulnerability detailsOn Thu, Jul 24, 2008 at 08:23:41AM -0700, Rick Moen wrote:
> Quoting Ruben Safir ([email protected]): > > > If the name server is using random ports how does the resolver know > > where to find it. I'm not likely to rewrite firefox. > > I was actually talking about random source ports for the outgoing > service request. You're right that having the service offered on > (listened for on) a random port would certainly not work. >
With due respect, I fail to see how random outgoing ports will provide more security, The server is still listening on a single known port and send responses from a random port (one that is hopefully not being used for vnc) but to connect to a known client port.
In of itself, how is that going to help security?
Ruben
> > _____________________________________________ > conspire mailing list > [email protected] > http://linuxmafia.com/mailman/listinfo/conspire
-- http://www.mrbrklyn.com - Interesting Stuff http://www.nylxs.com - Leadership Development in Free SoftwareRI Safir 1998
http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
"Yeah - I write Free Software...so SUE ME"
"The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society."
"> I'm an engineer. I choose the best tool for the job, politics be damned.< You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one."
� Copyright for the Digital Millennium
_____________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message ----- ----- Forwarded message from Rick Moen <[email protected]> -----
Date: Fri, 25 Jul 2008 16:44:32 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: Re: [conspire] DNS vulnerability detailsQuoting Ruben Safir ([email protected]):
> With due respect, I fail to see how random outgoing ports will provide > more security,
Because the man-in-the-middle attacker, posing as the queried recursive-resolver nameserver, has to send a forged response back not merely with the correct QID (transaction ID), but also delivered on the correct port. If the delivery port for responses, the one used to originate the query, is always 53/UDP, then it's much easier to forge a credible fake response -- 2^16 QID value possibilites, rather than those permutations plus 2^16 possible ports. ~32 bits of variability is better than 16, when you're trying to reject forged data.
> The server is still listening on a single know port and send responses > from a random port (one that is hopefully not being used for vnc) but > to connect to a known client port.
The queried server is not the problem. The problem resides with the recursive-resolver nameserver that's doing the asking: It's far too easy for an imposter to send it credibly faked responses -- that, in turn, can be used to poison the querying nameserver machine's cache.
That is why the problematic scenario is a recursive-resolver nameserver that sends its recursive-resolver requests always on UDP port 53, that also caches received data. (It also explains why processes that send out recursive queries but don't cache the results -- libc's "stub" resolver and most "firewall" appliances' nameservers being obvious examples -- aren't a problem: You can send them poisoned information, but that information won't persist.)
_____________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
Rick Moen [rick at linuxmafia.com]
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 <[email protected]> -----
Date: Sun, 3 Aug 2008 17:58:19 -0700 To: [email protected] From: Eric De MUND <[email protected]> Reply-To: Eric De MUND <[email protected]> Subject: Re: [conspire] DNS vulnerability detailsHello,
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.comStatic 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; IDHCP-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."Micheal [sic] Ray Richardson, on the New York Knicks
Eric De MUND | Ixian Systems | Jab: [email protected]/main [email protected] | 650 Castro St, #120-210 | Y!M: ead0002 ixian.com/ead/ | Mountain View, CA 94041 | ICQ: 811788
_____________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message ----- ----- Forwarded message from Rick Moen <[email protected]> -----
Date: Mon, 4 Aug 2008 13:19:15 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: Re: [conspire] DNS vulnerability details(Getting back to your question from yesterday):
Quoting Eric De MUND ([email protected]):
> 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 [email protected] http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
Rick Moen [rick at linuxmafia.com]
----- Forwarded message from Rick Moen <[email protected]> -----
Date: Tue, 5 Aug 2008 13:38:43 -0700 From: Rick Moen <[email protected]> To: [email protected] Subject: Re: [conspire] DNS vulnerability detailsWhile I'm still on this kick:
> 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]
It's important to realise: The IT press, by and large, don't understand anything about this issue, either -- beyond there being a security problem, and software patches. Remember, an IT reporter tends to be some guy or gal who, back when they were doling out asignments, showed ability to type and knew where the "Enter" key was. (There are honourable exceptions, and also even the really clued ones are under constant deadline pressure and perforce rely on what they hear from elsewhere.)
The story about client libraries -- called "stub" resolvers because they have just smart enough resolver code to articulate the query and offload them to one or more real recursive resolver, listed in /etc/resolv.conf -- is a case in point. The IT press don't get it.
I've commented online about Apple incrementing the versions of BIND9 shipped with OS X 5.4.x and 5.3.x, as part of their July 30 service pack (Software Update 2008-05). That was in response to a Computerworld story saying security experts were ragging on Apple for slowness -- for which complaint there was some minor justification. (BIND9 is included with OS X, but not enabled by default, and in fact requires some serious neepery to enable.) http://www.computerworld.com/comments/node/9110907?page=1
However, such news stories, and public comments on them, have been also complaining about OS X's, Linux/glibc's, and other OSes' DNS resolver clients being vulnerable, as if that were a significant problem. But it isn't -- for lack of a DNS cache to poison.
_The Register_ is always among the news outlets useful for alarmism without obvious clue: "Apple DNS patch doesn't patch Mac clients" (http://www.theregister.co.uk/2008/08/01/osx_still_vulnerable/)
Both researchers found that OS X clients fail to adequately randomize DNS source ports, allowing attackers to poison the caches of DNS servers that run on the operating system.
That's a horribly garbled recounting of the facts, and misleading. By contrast, what the security researcher alluded to, Andrew Storms of nSync and Swa Frantzen of Section 66, actually said was perfectly accurate and is reasonable perspective: They merely pointed out that the OS X "Leopard" 10.5.4 / "Tiger" 10.4.11 resolver uses predictable source ports on queries, and comment it should be fixed at some point.
FreeBSD's libc has gotten fixed probably somewhere in the recent past, and I hear that the Linux 2.6.26 kernel includes code that randomises UDP source ports despite the underlying weakness in glibc's resolver library code (the mess borrowed from BIND8) that gets called. (I'm a little unclear on the particulars.)
So, basically, improved port randomisation in client resolvers is getting rolled out with newer OS kernels.
Having access to reliably random data is actually a quite difficult problem, and unfortunately many programmers get bitten by the results of trying to punt the problem, e.g., by just tapping into the OS's /dev/random or /dev/urandom. The former tends to be pretty good (but not great) on most 'Nixes including Linux -- but tend to exhaust the system's "entropy pool" quickly. The latter (urandom) is an unlocked random generator that re-uses the internal pool, so it produces more numbers before conking out, but of lower quality.
A cautious programmer would look at that situation, and think "Gosh, if my code needs reliable random data, I guess I need a decent random number generator library (RNG), rather than just punting to the OS." Which is indeed what smart nameserver authors did, a long time ago. Compare:
Caching recursive resolvers: o BIND9: Wasn't smart, recently patched to compensate o MaraDNS: Author built in a custom RNG from the beginning o PowerDNS Recursor: Retrofitted a custom RNG in March 2008, after someone filed a security bug anticipating the Kaminsky issue o djbdns/dnscache: built in a custom RNG from the beginning, and the author made a point of warning everyone else of the pitfall o Unbound: Author built in a custom RNG from the beginning
Caching forwarders: o pdnsd: Author built in a custom RNG from the beginning o dnsmasq: Wasn't smart, recently patched to compensate
_____________________________________________ conspire mailing list [email protected] http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
Kapil Hari Paranjape [kapil at imsc.res.in]
Hello,
On Tue, 05 Aug 2008, Rick Moen wrote:
> ----- Forwarded message from Rick Moen <[email protected]> ----- > > Date: Tue, 5 Aug 2008 13:38:43 -0700 > From: Rick Moen <[email protected]> > To: [email protected] > Subject: Re: [conspire] DNS vulnerability details > > > 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?
While this is generally true, I am a bit worried about systems where one runs "nscd". (For those not in the know, "nscd=name service caching daemon" which caches a number of things for the libc resolver stub.) Does "nscd" aggravate the problem?
I know your response is likely to be "Do not run this little horror!" but it seems to be required if one is running NIS. Of course, the next question would be why one is running NIS in 2008!
Regards,
Kapil. --
Rick Moen [rick at linuxmafia.com]
Quoting Kapil Hari Paranjape ([email protected]):
> 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?
> While this is generally true, I am a bit worried about systems where > one runs "nscd". (For those not in the know, "nscd=name service > caching daemon" which caches a number of things for the libc resolver > stub.) Does "nscd" aggravate the problem?
Yes, it absolutely does. (In separate parts of discussion of this issue on various threads, I did footnote my comments to say "This of course is not true if the local system is caching DNS hosts data using nscd.")
> I know your response is likely to be "Do not run this little horror!" > but it seems to be required if one is running NIS. Of course, the > next question would be why one is running NIS in 2008!
Hosts on NIS, NIS+, or LDAP-based networks all tend to run nscd -- and there are a lot of legacy NIS-type networks out there, not to mention new deployments using LDAP directory services. It's a standard part of such configurations because it caches a great deal more than just hostnames (users, groups, services, RPC service ports, netgroups, etc.).
Long before this current DNS affair, though, it's been my strong recommendation that such users carefully disable nscd's caching of hosts data, in /etc/nscd.conf . For one thing, all versions of nscd for Linux through the present day ignore TTL (time to live) on cached DNS hostname data. In other words, its caching of such data is brain-dead. (I am told that this bug is soon to be fixed.)
I can tell you from experience, even on LANs with very heavy NIS/NFS activity, disabling that caching does not noticeably impair performance. And, of course, if you want to have local DNS caching, nothing prevents you doing so by running a genuine caching recursive-resolver daemon alongside nscd.