Slashdot Mirror
Bind 4 and 8 Vulnerabilities
eecue writes "The world's most popular DNS package is once again vulnerable. Even the advisory says it's only a matter of time before worms are written.... just like a couple years ago. I guess this is why i run tinydns."
Escape your binds, use djbdns.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
> Does TinyDNS support internal and external views?
Yes. This page shows you how http://cr.yp.to/djbdns/tinydns-data.html
Slashdot? Oh, I just read it for the articles.
linx pro has more information on the exploit, including patches to fix it.
Does MS fix their vulnerabilities that fast? Judging by the number of klez variants in my inbox, I'd say "no".
Come on, Bind 9 has been out for some time, so don't flip out!
[] Most smaller networks don't need a large (and dare I say buggy) installation of BIND.
[] May I suggest djbdns rather than BIND? Its creator says "every step of the design and implementation has been carefully evaluated from a security perspective. The djbdns package has been structured to minimize the complexity of security-critical code. dnscache is immune to cache poisoning. It is advisable to use the package as a secure alternative to BIND."
[] May I suggest Dnsmasq , which is described by its creators as a "lightweight, easy to configure DNS forwarder designed to provide DNS (domain name) services to a small network where using BIND would be overkill".
If you celebrate Xmas, befriend me (538
It's not surprising that bind 4 and 8 have the same vulnerabilities - they're based on the same code base, after all. Bind 9 was 100% rewritten, is modular, and actually *checks its inputs*, avoiding buffer overruns and such.
It uses RFC-specified zone file format, it's extremely functional (internal/external views of DNS based on query source, TSIG authenticated DNS transactions, DNSSEC authenticated DNS records).
In the couple of years the bind 9 code has been out there, the only vulnerabilities it's had caused the server to shut itself down immediately, as it realised something was wrong with its input. That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.
The potential for a passive worm is actually fairly high, given that the exploit needs to come in response to a DNS query: The worm infects a DNS server, and waits for queries. It responds to those queries from other DNS servers by attempting to infect them.
The nasty parts: Enough people dual-use their DNS servers (serving as both authoritative master for outside and for their own lookups) that you could get lots of authoritative masters. It also does NOT scan.
It could be made even stealtier if the exploit, on failure, would still function. On success, it of course functions normally. This might be harder, but, if so, it would be really REALLY hard to detect such a worm.
It would take a bit of writing to get right, so there is a good window in which to patch your machines. So patch SOON.
Test your net with Netalyzr
BIND 8.3.3 is the latest version of ISC BIND 8. We strongly recommend that you upgrade to BIND 9.2.1 or, if that is not immediately possible, to BIND 8.3.2 due to certain security vulnerabilities in previous versions. 8.3.3 contains a security fix in libbind. If you have BIND 8.x you need to upgrade.
ISS did not inform any of the Unix vendors.
They are pretty pissed about it.
Alan Cox's response was "Well we can all express our deep regret at the inability of the ironically named ISC to work with the internet and society in all the announces."
BTW, Bind 9 does not fix all of these probems and the fixed versions will be out next week.
This is not the first time that ISS has released information like this without informing the vendors ahead of time.
"Trademarks are the heraldry of the new feudalism."
It was mentioned on the FreeBSD-Security list this morning that ISS had informed vendors that they were going to go public with this advisory tomorrow and not today. So in answer to your question, Yes, the vendors have apparently been notified.
This however appears to be yet another situation where ISS has gone ahead and released an advisory before the vendors have actually had a chance to make patches available to the public.
This is supposed to be a security firm that is trying to assist the public in keeping their boxen secure? If so, I'm really scared of the firms that are out there really trying to do damage.
Answer: OpenBSD See subsection 6.8.3.1
and read this for why
ZERO ZERO ONE ZERO ONE ZERO ONE ONE! Just brushing up for my next big invention: Ethernet over Voice (EoV)
For me, it is not really an option to use a tinydns or any other DNS solution other than BIND. Upgrading to BIND9 is not really an option for me either. I work for a large multinational, and we have a lot of UNIX servers (Sun, IBM, and HP in terms of numbers). I get hardware and software support direct from the manufacturer, and if I install an application, or a version of an application that my vendor does not support, I am on my own. These 24-7 support contracts are important to us in being able to sell our services and maintaining our SLA's and availability targets. Those issues aside, I do not want to have to explain to the PHBs that we cannot get support on a particular problem because the application in question is not supported by Sun, or that IBM only supports version 3.4 and we run version 4.0.
So, it is all well and good if someone out there has the choice to install some other software, but keep in mind that it is not necessarily an option for everyone...
*** Where are we going? And what's with this handbasket?
Hey, this guy offers $10,000.00 to anyone who can disprove his *AHEM* theory, and no-one has taken HIS money.
Be wary of any facts that confirm your opinion.
Two of the attacks are DoS: You crash the server, end of story. One, the buffer overflow, can potentially execute code.
The only "gotcha" in that exploit is that an attacker needs to control a DNS server which the victim DNS server queries. Thus it is a passive attack, the victim must query you, not the other way around.
That is why the attacker uses a passive worm: The worm infects a DNS server, which in addition to being the local DNS server, serves as the authoritative master DNS server for some domains. When another DNS server queries the infected authoritative master, the authoritative master's response is designed to compromise the requesting server.
This compromise is followed by a transfer of the worm code itself, and now the victimized server is now infected as well.
As I said, this doesn't scan, which makes it particularly nice and stealthy.
You could also make an active scanning worm as follow: There are 2 kinds of nodes, authoritative DNS servers and other DNS servers. If you infect an authoritative DNS server, the worm knows it. Otherwise, it knows the authoritative DNS server it was infected from.
The worm "scans" by sending DNS queries (ideally with forged from addresses) which will trigger a lookup from the known corrupted authoritative server. This can then go through the net, rather noisily, and infect all servers which accept remote queries. This process can be sped up considerably by looking through the local cache for a list of all DNS servers that the corrupted machine knows about. Rough guess? Less than an hour to infect everything which can listen to the net, and you still have the passive attack to get DNS machines behind firewalls etc.
The fortunate thing: Although the possible worms are either very fast (lots of vulnerable machines, topological speedup from using the cache) or very stealthy (no scanning at all, a contageon strategy), both techniques require a fair amount of BIND specific programming to develop and release: You need to not only craft the exploit, but keep bind running and transmit the exploit.
So no kiddiot can simply drop exploit code into scalper.c and get it to work, instead there is a considerable amount of programming needed. So we do have a significant time window to patch machines, but they do need to be patched because it is a very "worm friendly" exploit pattern.
Test your net with Netalyzr
BIND 9 is slower than BIND 8, because it does a more correct job, but it's not significantly slower for most applications. If you are running a root name server, you will have to buy bigger iron. If you are running a corporate nameserver, you probably won't. For home use, BIND 9 will perform nicely on a 486 (I run it on a Soekris board, for example).
BIND 9 is also not bug-for-bug compatible with BIND 8, so there are some things you can do in BIND 8 that are broken, that you can't do in BIND 9. So upgrading can require some rework if you happen to have unwittingly tripped over those bugs.
On the other hand, BIND 9 is a complete, ground-up rewrite of BIND. It works better, is easier to use, and because of the strict practices that were followed in implementation, is much more reliable.
BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.
(I used to work for the ISC, so you might think I'm biased, but I wasn't involved with the ISC BIND project, so it's more that I got to look on while they did it, and was there to see some of the design work they did to make it more reliable, I know the engineers who did it, and I really think they did a great job.)
With all of the security news lately, I am too scared to run Apache, IIS, Exchange, lpr, lprng, mySQL, PostgreSQL, Outlook, Outlook Express, map Netware drives to Win 9x clients, X11, use any program that requires glibc, or use BIND 4 or 8 or any DNS for that matter. My computer sits in a locked closet, lacks input devices, and runs only the OpenBSD kernel and nothing else.
Another option, if one does not need recursive caching is posadis. There is also pdnsd, which only provides recursive DNS service.
Security history of various DNS servers:
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Sendmail likes to _blame_ things on the OS that are really (at least /usr is /usr be group-readable. (If it were world /usr, wasn't
partly) sendmail's fault. For example, being insecure if
group-readable. That's just silly; there's nothing inherently
insecure about having
writable, that would be something else.) (It was
it? It's the thing you have to change in the filesystem to get
sendmail to be secure on OS X.) IMO there's no excuse for sendmail
to blame that on the OS; in the first place, sendmail should be
secure regardless of the filesystem permissions, and in the second
place if it doesn't need to read such places it should run as a user
with fewer permissions (e.g., with its own group like Apache does).
qmail, for all the complaints you can make about its license, at
least takes responsibility for its own vulnerabilities.
Are weaknesses in the OSes _partially_ responsible for some of those
vulnerabilities? Well, sure, but the weakness is exploited through
sendmail and does not have an impact on competing implementations;
that makes it sendmail's problem in my book, and blaming it on the
OS is just a way of shirking responsibility. Do you report the
vulnerability in the OS? Heck, yes, but you also fix your app to
not be exploitable through it. The sendmail people need to drop the
"don't blame sendmail" attitude and write secure software. I know
it's hard being the leading server software in a particular market,
but when openssl can be exploited because of an issue in certain
kernels, they patch openssl. When the openssl issue causes some
Apache installations to be vulnerable, the Apache people release
an advisory. It shouldn't be about placing blame; it should be
about _fixing the problem_. The sendmail people are more interested
in pointing fingers.
Not that there aren't things you _can't_ work around, that have to
be fixed at the OS level. Keeping unauthorized local users out of
the data on a system without filesystem permissions (e.g., Win98),
for example, is not something that can be fixed by the app, at least
not easily. But at some point a line is crossed where the problem
_should_ be fixed in the app. Especially if it's an app that listens
on ports or otherwise receives data from random entities on the net.
sendmail has a long history of being vulnerable -- way worse than
BIND, right up there with IIS and Outlook. And it's going to
continue to be that way for as long as they keep wanting to blame
their issues on the OS.
Cut that out, or I will ship you to Norilsk in a box.