[ISN] Thoughts About "Protection Against BIND"

[InfoSec News]

http://www.circleid.com/article/774_0_1_0_C/

By Paul Vixie
Oct 11, 2004 

Imagine my surprise upon reading a BBC article which identified ISC 
BIND as the top security vulnerability to UNIX systems. At ISC, we 
have striven for a decade to repair BIND's reputation, and by all 
accounts we have made great progress. "What could this be about," I 
wondered, as I scanned the BBC article for more details.

It turns out that BBC was merely parroting what it had been told by 
SANS.

OK, let's see what SANS has to say:

 Top Vulnerabilities to UNIX Systems (U)

 U1. BIND Domain Name System

Ouch! So at this point I'm asking, "OK, what have we done wrong this 
time?"

 U1.1 Description

 The Berkeley Internet Name Domain (BIND) package has become the 
 worlds most widely used implementation of the Domain Name Service (DNS). 
 DNS is a critical system that facilitates the conversion of hostnames 
 (e.g. www.sans.org) into the corresponding registered IP address.

Yeah, yeah, so far, so good. What's the problem, though?

 Due to the ubiquity and critical nature of BIND, it has been made the 
 target of frequent attack.

Ubiquity isn't a vulnerability, though... So, I kept reading:

 Denial of Service (DoS) attacks, which generally result in a complete 
 loss of naming services to Internet sites, have long plagued BIND.

Um. Actually, DDoS attacks do not plague BIND. In fact, DDoS attacks 
have nothing to do with BIND per se -- a DDoS is an attack on a 
network, and will affect all services offered by that network, 
including web services like those offered by Amazon and Ebay. So, what 
can they mean? Are they among the many people who are confused about 
the difference between BIND (which is software) and DNS (which is a 
protocol and a service)? In other words, do they really mean that DDoS 
attacks have long plagued DNS?

If so, then the mystery actually just deepens. UltraDNS and Akamai 
both offer DNS services and both of them wrote their own software (so, 
they are not running BIND), yet both of them have been the victim of 
high profile DDoS attacks which affected very visible customers 
including Google. Why would SANS single out BIND as a DDoS target, 
when DDoS attacks are not against software, and recent DDoS attacks 
against DNS have not involved BIND?

So, still mystified, I kept reading:

 Various other attacks such as buffer overflows and cache poisoning 
 have been discovered within BIND.

Well, OK, they've got that part right at least. The BIND software that 
was part of BSD was terrible. And after wrestling with it for a 
decade, ISC decided to rewrite it from scratch. The result, BIND9, is 
pretty solid.

 Although the BIND development team has historically been quick to 
 respond to and/or repair vulnerabilities, an excessive number of 
 outdated, mis-configured and/or vulnerable servers still remain in 
 production.


By the above-quoted text, this whole article is due to older versions 
of BIND and mis-configured servers running BIND, yet the title of the 
article was simply "BIND Domain Name System". This seems somewhat 
disingenuous.

But I kept reading.

 A number of factors contribute to this condition. Chief among them 
 are administrators who are not aware of security upgrades, systems which 
 are running BIND daemon (called "named") unnecessarily, and bad 
 configuration files. Any of these can affect a denial of service, a 
 buffer overflow or DNS cache poisoning.

Yes, that's all true. I heard someone from Microsoft say that if they 
could just get people to upgrade from Win/95 and apply published 
patches, the whole Internet would be safer. And that's also true. I 
don't quite understand SANS's reason for mentioning it, though. 
"Unpatched Or Misconfigured Software Is Unsafe" is not exactly 
headline news. But if they like that one, how does "Either A Democrat 
Or A Republican Will Be Next U.S. President" sound? It's disturbing, 
it's true, and everybody already knows it, so, "so what?"

But you've got to understand something -- I know some people who work 
at SANS and those people -- the ones I know -- are not idiots. So, I 
kept reading:

 Among the most recently discovered BIND weaknesses was a denial of 
 service discussed in CERT Advisory CA-2002-15. In this case, an 
 attacker could send specific DNS packets to force an internal 
 consistency check which itself is vulnerable, causing the BIND daemon 
 to shut down. Another was a buffer overflow attack, discussed in CERT 
 Advisory CA-2002-19, in which an attacker could utilize vulnerable 
 implementations of the DNS resolver libraries. By sending malicious 
 DNS responses, the attacker could exploit this vulnerability and 
 execute arbitrary code or even cause a denial of service.

I love this! Thank you, SANS, for helping to get the word out. We've 
been telling our vendors and our user community to stop running or 
shipping BIND versions containing these vulnerabilities for years now. 
Several years, in fact. Ever since we cooperated in disclosing and 
repairing those problems. But it's 2004, and those two vulnerabilities 
were published in 2002, so why would it make any sense to announce 
them in 2004? Are they still newsworthy?

 A further risk is posed by a vulnerable BIND server, which may be 
 compromised and used as a repository for illicit material without the 
 administrator's knowledge, or in stepping-stone attacks which use the 
 server as a platform for further malicious activity.

I hate this! Damn you, SANS, for making me remember the fictional 
State Science Institute and its condemnation-without-facts of Reardon 
Metal. For the record, there has never been an exploit of the kind 
you're describing in any version of BIND9, and there is no known 
exploit of this kind in the latest version of BIND8, or even the 
latest BIND4.

OK, so by this point in reading SANS's article, I'm angry, and I'm 
starting to think of the article as a "hit piece". But I kept reading:

 U1.2 Operating Systems Affected

 Just about every UNIX and Linux system is distributed with some 
 version of BIND. The installation of BIND can be intentional for 
 server purposes or unintentional in a general installation. A binary 
 version of BIND is also available for the Windows platform.

It is widely considered to be good practice to run a non-authoritative 
BIND server on every host, for the purpose of caching-for-reuse all 
data fetched from the global DNS. And for the record, full buildable 
open source code is available for BIND on Windows -- not just 
binaries.

"What can they be thinking?" is what I was thinking at this point. 
Onward:

 U1.4 How to Determine if you are Vulnerable

 Any DNS server running a version of BIND that was bundled with the 
 operating system, should be compared against the current patches 
 released by the appropriate vendor. If a running version of BIND is 
 compiled from source from the Internet Software Consortium (ISC), it 
 should be checked to ensure it is the latest version. Outdated and/or 
 un-patched versions of BIND are most likely vulnerable.

All true, every word of it.

 On most system implementations, the command "named -v" will show the 
 installed BIND version enumerated as X.Y.Z where X is the major 
 version, Y is the minor version, and Z is a patch level. Currently 
 the three major versions for BIND are 4, 8 and 9. If on is running a BIND 
 server built from source, one should avoid using version 4, opting 
 instead for version 9. You can retrieve the latest source, version 
 9.3.0rc2, from the ISC.

Actually, the latest version is 9.3.0 (it's not just a release 
candidate any more). But it's sure nice to hear them calling us ISC. 
Just "ISC", though, please, and never "the ISC". (A lawyer told me to 
say that.)

 A proactive approach to maintaining the security of BIND is to 
 subscribe to customized alerting and vulnerability reports, such as 
 those available from SANS or by keeping up with advisories posted at 
 OSVDB. In addition to security alerts, an updated vulnerability 
 scanner can be highly effective in diagnosing any potential 
 vulnerabilities within DNS systems.

Or, interested parties could join ISC's BIND Forum, with or without 
the Advanced Security Notification option. You'll not only get the 
straight scoop on upcoming releases, you can help set our priorities, 
and help pay the production cost of BIND. We (ISC) are a nonprofit 
corporation, and BIND is completely free software -- more free even 
than FSF/GNU/Linux, since it can be bundled or repackaged or otherwise 
redistributed with or without source code, and with no license or 
royalty payments of any kind.

Or, interested parties could engage ISC in a support contract for 
BIND, which would include several of the above-described benefits of 
the our BIND Forum, but would also get you high-quality phone/e-mail 
support.

(I'm not just setting the record straight -- a lot of folks just don't 
know about ISC's BIND Forum and BIND Support offerings.)

Onward:

 U1.5 How to Protect Against It

OK, wait just a minute. They've got a section entitled "How to 
Determine if you are Vulnerable" and now one entitled "How to Protect 
Against It" and the "it" in question is (from the title of this 
article) "BIND Domain Name System". Do folks really need to determine 
if they are vulnerable to BIND? And, for that matter, do folks really 
need to be protected against BIND?

But I digress. Fortunately we're almost at the end of this thing. 
Onward:

 To generally protect against BIND vulnerabilities: 

 Disable the BIND daemon (called "named") on any system which is not 
 specifically designated and authorized to be a DNS server.

This would be a mistake. If your local DNS policy makes every
workstation and every server into its own "caching recursive
forwarding name server" then you are helping yourself and helping the
Internet and you shouldn't stop just because SANS tells you to. But
one of the other things they recommend is a great idea:

 Apply all vendor patches or upgrade DNS servers to the latest 
 version. For more information about hardening a BIND installation, 
 see the articles about securing name services as referenced in CERT's 
 UNIX Security Checklist.

For patches and checklists, you can also just visit ISC's BIND Home 
Page at <http://www.isc.org/sw/bind>. ISC publishes links to useful 
things about BIND configuration, even if they originate elsewhere.

 To complicate automated attacks or scans of a system, hide the 
 "Version String" banner in BIND by replacing the actual version of 
 BIND with a bogus version number in the "named.conf" file options 
 statement.

This is just foolishness. Any attacker whose age is requires more than 
one digit to describe will just "fingerprint" your system, including 
your kernel and all of your services including DNS. They don't need to 
know what version string you report, and they wouldn't believe it, and 
they've stopped asking.

And SANS ought to *know* that; moreover, they ought to be telling 
*you* that.

 Permit zone transfers only to secondary DNS servers in trusted 
 domains.

I'm not sure what this means but I think I don't like the sound of it. 
You should not do anything special about parent or child domains -- 
just create them, properly delegate them, and let DNS figure out where 
they are and how to reach them.

 Jail: To prevent a compromised BIND service from exposing ones entire 
 system, restrict BIND so that it runs as a non-privileged user in a 
 chroot()ed directory. For BIND 9, see: 
 http://www.losurs.org/docs/howto/Chroot-BIND.html

This is a great idea, which is why we have it as a standard BIND9 
feature, and why we describe it in the standard BIND documentation.

 Disable recursion and glue fetching to defend against DNS cache 
 poisoning

I think that what they mean is "don't run authority service and 
recursive service in the same name server", and this is good advice. 
It's so good in fact that we wrote about it in , specifically 
ISC-TN-2002-2. Yup, two years ago. I guess it isn't news?

 To protect against recently discovered BIND vulnerabilities: 

 For the Denial of Service Vulnerability on ISC BIND 9:
 http//www.cert.org/advisories/CA-2002-15.html

I'm sorry, I know this sounds catty, but... 2002 is "recent"?

 Multiple Denial of Service vulnerabilities on ISC BIND 8:
 http://www.isc.org/products/BIND/bind-security.html

Better still, just don't run BIND8 now that BIND9 is solid. But the 
URL they give makes good reading, even if I do say so myself.

 Cache poisoning via negative responses:
 http://www.kb.cert.org/vuls/id/734644

OK, to give SANS credit, they found something that's less than two 
years old. However, it's in BIND8. Oops. You should all upgrade to 
BIND9 now. Even FreeBSD now ships BIND9 as their default name server. 
BIND8 is dead! Long live the king!

 There exist many excellent guides to hardening BIND. One excellent 
 guide on hardening BIND on Solaris systems, as well as additional 
 references for BIND documentation, can be viewed at Running the BIND9 
 DNS Server Securely and the archives of BIND security papers 
 available from Afentis. You can also view documentation covering 
 general BIND security practices.

Those are good articles. But Jacco's site at <http://www.bind9.net/> 
is also very good, and includes all kinds of useful links. Education 
is good.

 Administrators can also look at alternatives to BIND such as DJBDNS 
 located at http://cr.yp.to/djbdns.html.

OK, so some of you were wondering why I bothered to respond to this 
obvious "hit piece" written by someone without much background in the 
field -- maybe the same yet-to-be-fired marketing wizard who came up 
with the name "Internet Storm Center" when the term ISC had another, 
much stronger, much older, meaning. I was going to Just Hit Delete -- 
something you should never do with spam, by the way! Until I saw the 
DJBDNS reference. Mr. Bernstein has what could politely be called a 
grudge against... well, almost everybody. His software seems to work, 
and it has a loyal and committed user base. But if you're going to 
look at alternatives to BIND, you need more options, and you need a 
better reason.

For more options, check out Nominum's ANS and CNS products, and 
NLNetLabs' "NSD", and Cisco's DNS/DHCP Manager, and Microsoft's 
Advanced Server product. (I'm sorry if I'm leaving somebody out, 
that's off the top of my head.)

For a better reason, discard "I don't want to have to learn about 
patches and apply them every year or two" since no vendor will ever be 
able to guaranty this. If you want help staying patched, talk to ISC 
about BIND support, or talk to your operating system vendor, or talk 
to your ISP. Help is out there.

My faith in and charity toward SANS has taken a sharp step downward 
today.

Paul Vixie
Maintainer/author, BIND4.9 - BIND8.1
Co-founder and President, ISC