Slashdot Mirror
New DNS Software to Address Security Holes
Ben Galliart writes "The Internet Software Consortium released on Monday another patchlevel to their ever popular BIND software package. The ISC has recommended that everyone using BIND upgrade to this latest version (BIND v8.2.2 patchlevel 3) due to security holes existing in previous versions. If you are using a version previous to BIND 8.2.1 then pay special attention to the ISC configuration hints on a new required TTL setting which should be added to every zone file. More information on the TTL setting is also available in RFC 2038. On a side note, those who enjoy the bleeding edge should read the ISC future plans page which now has information on the thread-safe/multi-processor ready BIND version 9 (major rewrite) going beta in January. "
It would be nice if some of the real security people out there would work toward a standard of intersystem daemon security. An SSH (SECIP) style public-key with trust (signed keys -- like PGP/GPG) system (in a library) that could be linked against by all those making daemons. BIND could link against it to authenticate messages it sends and receives, so could PING (for those of us who don't like pingfloods) and X.
Each daemon is starting to add its own security (Cyrus IMAP has several options) and they aren't inter-compatible. If there were a common library they were based on, it could be improved upon by all parties involved.
Hate to point out one of the greatest benefits of open source -- shared library code that you can modify -- and also one we are bad at actually doing.
- Michael T. Babcock <homepage>
- Michael T. Babcock (Yes, I blog)
Sure, it's not "prime time", yet! So? Give a bunch of computer phreaks the source, and they'll patch more bugs in a day than the entire BIND development team can find in a week. That's not to put the BIND team down, but a closed testbed network (typical for this kind of work) is not going to find bugs that'll crop up in the real world.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
There was a bug that made it into named-xfer that prevented AXFR from working properly. The change below will fix it... Hope this helps someone!
= =================== /proj/cvs/isc/bind/src/bin/named-xfer/named-xfer.c ,v
- Strabo
The following change should correct
the problem.
Index: src/bin/named-xfer/named-xfer.c
===============================================
RCS file:
retrieving revision 8.88
retrieving revision 8.89
diff -c -r8.88 -r8.89
*** named-xfer.c 1999/11/08 23:01:39 8.88
--- named-xfer.c 1999/11/09 20:36:54 8.89
***************
*** 2195,2201 ****
zp->z_origin, zp_finish.z_serial);
}
soa_cnt++;
! if ((methode == ISIXFR) || (soa_cnt > 2)) {
return (result);
}
} else {
--- 2195,2201 ----
zp->z_origin, zp_finish.z_serial);
}
soa_cnt++;
! if ((methode == ISIXFR) || (soa_cnt >= 2)) {
return (result);
}
} else {
I'm no DNS Expert(though I do admin my own personal domain) so there's a sense of rummaging through something much larger than I've grokked at this point.
Here's a useful chunk from the RFC:
"Negative caching" - the storage of knowledge that something does not
exist. We can store the knowledge that a record has a particular
value. We can also do the reverse, that is, to store the knowledge
that a record does not exist. It is the storage of knowledge that
something does not exist, cannot or does not give an answer that we
call negative caching.
What's now mandatory--
[RFC1034] provided a description of how to cache negative responses.
It however had a fundamental flaw in that it did not allow a name
server to hand out those cached responses to other resolvers, thereby
greatly reducing the effect of the caching. This document addresses
issues raise in the light of experience and replaces [RFC1034 Section
4.3.4].
Negative caching was an optional part of the DNS specification and
deals with the caching of the non-existence of an RRset [RFC2181] or
domain name.
Negative caching is useful as it reduces the response time for
negative answers. It also reduces the number of messages that have
to be sent between resolvers and name servers hence overall network
traffic. A large proportion of DNS traffic on the Internet could be
eliminated if all resolvers implemented negative caching. With this
in mind negative caching should no longer be seen as an optional part
of a DNS resolver.
HTH.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
While I'm encouraged that they are fixing the problems with the package, I wish there were an easy way to deal with the inherent problems with the protocol itself. It's still fairly trivial to poison DNS caches, and lookups are still not encrypted, which although not much of a security issue by itself, it's a bit of a privacy issue. We've come to a point where if a program relies on reverse DNS lookups, any DNS expoit used against it is considered a security problem with the program, not DNS. The truth is, however, that the DNS system should be reliable enough that these types of attacks wouldn't even exist. Don't get me wrong, I applaud their work for fixing the bugs that they have, but there is some basic protocol work that needs to be done before I'm happy with it. Here is a interesting example of DNS quirks.
If you need to point-and-click to administer a machine,
Go to the future plans page and look for the list of contributors down at the bottom. Notice who is missing from the list? Of course, it's our old friend NSI. It's rather appalling that the company most dependent on the performance of BIND is one who sees no benefit in helping with it's development.
World Beach List, my latest project.
As some have pointed out, there are many protocols that are "open" that could be updated to do something like what I've mentioned. Just to put a few more of my thoughts down on virtual paper (PS, the thoughts are GPL'd if that's possible; you can use them for any GPL project :).
I'd like to see something along the lines of an authenticaed ident server as a necessary part of this protocol. It wouldn't be a daemon running (like ident) to identify callers, but the daemon (like BIND) connecting to the remote daemon would identify who it is (SSH2 style) and what machine it is running on (also SSH2 style).
Why identify both the machine and the daemon? Because a daemon could be loaded up by a (bad) user and run on a different port, linked against the authentication library and attempt to send bad data "out there" to other machines. In this way, the daemon itself would have identity information either created at compile-time (and linked in via header) or some other method. Of course, the daemon would have to be unreadable by anyone but root (or its own username), but that's ok, right?
Sending data over a secure connection works just fine if you don't want people snooping, but authenticating a daemon requires more than that. In the case of DNS, one of the big factors is authenticating that the DNS server you've connected to is indeed who it claims to be.
XNTP3 does this as well (in a basic form) if you want to create time peers that authenticate off each other.
RFC ideas anyone?
- Michael T. Babcock <homepage>
- Michael T. Babcock (Yes, I blog)
As per RFC 2308 (DNS NCACHE), the SOA minimum field now is the NCACHE TTL value. In the past, the SOA Minimum field had three meanings:
1. The minimum TTL for that zone
2. The default TTL for records without one specified
3. The TTL of negative responses
#1 was never used, #2 is only relevant on the master server (since TTL is explicit during a zone transfer), and #3 is now the ONLY meaning for the SOA Minimum field.
What this means is that to fulfill #2 (default TTL), you will now have to add the $TTL directive to all zone files you are master of, and modify the SOA Minimum field to something more appropriate for the NCACHE TTL. Your zone file would look something like this:
; Example of $TTL and SOA
$ORIGIN whatever.org.
$TTL 86400 ; Default TTL (1 day)
@ IN SOA ns1.whatever.org. postmaster.whatever.org. (
1999111001 ; Serial
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
604800 ; Expire (1 week)
1800 ) ; NCACHE TTL (30 minutes)
These values are, of course, not set in stone - just an example. However, most people set their SOA Minimum field to somewhere around 1 day, give or take, to reduce load on queries to their server. This value is likely to be too high to cache NEGATIVE answers, so should probably be adjusted.
As for the $TTL directive, just add it before the SOA record, usually with whatever was the previous value for the SOA Minimum. If it is not designated, BIND will issue a warning, but will use the SOA minimum instead. Annoying to see all the warnings if you have a large number of zones, but it doesn't cause problems other than the logging:
Nov 10 12:15:12 thanatos named[14344]: Zone "whatever.org" (file whatever.org.db): No default TTL set using SOA minimum instead
This information only pertains to BIND 8.2.0 and above (including 8.2.2-P3, obviously).
- Strabo
CERT should be telling admins about this. Where are you guys? No mention on bugtraq or securityfocus. According to strabo's post, 8.2.2p3 is broken. ISC, how 'bout releasing 8.2.2p4??
This is the FBI. We've recently gotten word of a new kind of internet protocol called 'dns'. We require that you immediately install backdoors into the protocol so we can secretly monitor all dns communication. It is not relevant that information in dns servers are publically available. This will be done at once. We will not provide assistance to you to do this. Thank you for your continued compliance.
Sorry.. given the proxmimity to the wiretapping article.. *somebody* had to do it! =)
--
Just went to the LISA conf yesterday for a tutorial on BIND given by Vixie himself. He spent a bit on the logistical/technical issues DNSSec. Just a quick run down.
I have nameservers that can get well over a 1000 requests per second (not that they actually answer them all:). I'm not going to encrypt every response, it's just not that important. It is far more practical to use this as an internal security measure but for the internet - don't make me laugh.