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,
This is very bad, but I don't think we should be suprised.
One of the *BSD project leaders said after the 4.9.? remote exploit that he doesn't trust the BIND code.
It's possible to run the name server in a chroot jail as a non-root user. That won't solve the DoS problems, but at least you won't get "owned".
Hmm... I had a URL with instructions but now I can't find it... Anyone have a link?
One of the issues floating around BIND lately has been it's use of RSA authentication. Of course, RSA is patented (yuck). Debian has dealt by redistributing BIND without the RSA stuff. Does this version follow suit? More non-free stuff?
I for one will be quite happy when Dents is a suitable replacement for BIND. BIND seems to be quite old and crufty at this point, and Dents has a very nice design so far. Modular everything, and CORBA for administration. No more overloading of signals and crap like that. Whee!
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.
Wonder if the NSA will allow exports of this new "strong programming" version of the daemon. I mean, if American Nationalist Loyalists can't just hack into any system they want, this seems to me like a Bad Thing. Certainly a security threat :)
Can your IM do this?
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
It seems like slashdot is such a cesspool of
ignorance about the fundamental functioning
of most software, not to mention TCP/IP and
supporting Internet protocols. Recommendation:
go read up on IETF working groups DNSIND and
DNSOPS, etc.
Yep, I use it. But then again, I'm a Heinlein fan ...
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! =)
--
Anyone portscanning me is logged and added to ipchains' list of loons, goons, and 31337 h4x0rZ.
I've heard a few people use it, but it is getting rare.
I saw the thing about people testing bind for 'Y2K readiness' using the zone serial number.. they totally miss the point of zone serial numbers %)
Either that or they're really scamming some companys big time fixing this 'bug.'
In case people are confused about how others use dates in the serial number, it's just a little trick sys admins use so they can see when someone last updated the zone.. generally people use the YYYYMMDDR thing like it said.. the R is the number of times in the day that the zone file was updated. the only thing about doing this is that if you put '10' in R and then the next day you start at 1 again, the number will be smaller than the previous day, e.g. 1999032710 and 199903281.
I prefer the simple 'increment the number' way personally.
rm -rf ~/.signature
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.
Does anyone have a mirror for this? My download is stuck on 1%
I'm curious if Microsoft DNS Server has this same problem? of is this one of those issues where no sophistication = no security holes. like the military using Apple web servers? please don't replay with endless ramblings about how Microsoft DNS is inferior, and how bill gates is an evil monster sent from the devil to destroy mankind. -Jon
this is my sig.
ftp://ftp.isc.org/isc/bind/src/8.2.2-P3/patch4
I'd like to run two dns servers on the same machine, one for queries coming from the internet and the other for queries coming from the lan.
Yeah, I know. The "right" way to do it is to run the internal dns somewhere besides on the firewall, but I've got a scarcity of Unix boxen (read ONE).
Wondered if it was possible to configure BIND to bind to a specific address or port? Perhaps with tcpserver?
Robert August Vincent II root@picus.com, hostmaster@pillars.net What will YOU be doing on 1/1/3000?
According to ISC's website:
1 9991108.html
"ISC has discovered (or has been notified of) six bugs which can result in vulnerabilities of varying levels of severity in BIND as distributed by ISC. CERT has been notified of all of these issues."
Also, "In addition to fetching the bind-src tarball, you will need to fetch and apply the following patch. If you do not apply this patch, your zone transfers may fail."
- ftp://ftp.isc.org/isc/bind/src/8.2.2-P3/patch4
This is from:
http://www.isc.org/products/BIND/bind-security-
- Strabo
You don't need to encrypt DNS responses. (Why would you; it's public information anyway?) You need to sign DNS responses, but you can sign each RR once and cache the signature. He's probably right about the 512-byte problem, but that's what you get for building such limitations into your protocols.
(in Homer Simpson's voice)
Contrary to the popular belief, there indeed is no God.
...the Slash code was enhanced such that any post within the first 50 per article which contained the words "first post", in that order, in the topic, was automatically deprecated to -2?
its a pile of bullsh*t and keeps CERT from being useful. they are a black hole of security breach information. sad really.
a lot of other security sites are the same. *shrug* if you are concerned about security, subscribe to each and every security-* or announce-* mailing list that exists for the critical software you run.
Sarcasm.
i just secured bind according to a document i found on linux.com
it is now running as its own user and chroot, but how come it doesnt log anymore? anyone has an idea?:)
(posting anonymously for obvious reasons;)
Bind 8.2.2 is introducing a serious problem - it can't be exported from the US thanks to the RSA code. That's why we can't release updated packages right now. (Anyone in non-US downloading bind from ISC is exporting weapons, by the way).
This message is provided under the terms outlined at http://www.bero.org/terms.html
Turn off your computer, and disconnect your telephone. Who needs 'em? Really. The best way to reject their shit is to adapt a new paradigm that they don't understand. It will take them years to figure out that folks can live without a telephone or computer. In the meantime, the disconnected will enjoy unprecedented freedom and privacy. Cool.
Can someone provide some pointers as to how to set up BIND securely if you are only aiming to run it as a primary or secondary name server? (I think that implies no zone transfers or forwarding). And should it be running chrooted (under FreeBSD) or does that provide additional implications?
Btw, the post that I am replying too contains probably one of the most important URLs that will be posted in this whole DNS discussion. I hope some moderators catch on to this fact. :)
check the jargon file
#define X(x,y) x##y
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,