Slashdot Mirror
High Severity BIND Vulnerability Advisory Issued
wiredmikey writes "The Internet Systems Consortium (ISC) and US-CERT have issued a high severity vulnerability warning, discovered by Neustar, which affects BIND, the most widely used DNS software on the Internet. Successful exploitation could enable attacker to cause Bind servers to stop processing all requests. According to the disclosure, 'When an authoritative server processes a successful IXFR transfer or a dynamic update, there is a small window of time during which the IXFR/update coupled with a query may cause a deadlock to occur. This deadlock will cause the server to stop processing all requests. A high query rate and/or a high update rate will increase the probability of this condition.'"
"There have been no active exploits known, and versions 9.7.1-9.7.2-P3 versions of BIND are affected. US-CERT encourages users and administrators using the affected versions of BIND to upgrade to BIND 9.7.3 "
I wonder how long it'll be until FreeBSD rolls a security update out for this.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
What about versions before 9.7.1? Looks like this vulnerability affects only Bind servers within the specific range: 9.7.1-9.7.2-P3
Let me ask a question, when alerts come out like this that explain a vulnerability, do they always state the problem the way it happens?
Like, if someone understood how to exploit this vulnerability, are they really going to shut down DNS services or could it be that there is a worse vulnerability underneath? For instance, could this actually be a call to patch something that allows for DNS spoof, where someone does not want the issue to have wide awareness?
I'd hardly call hosts files obscure...
Also, restricting name resolution to host file only does not "defacto limit the webservers that employees may visit" as this file is never consulted if the user decides to access a webserver via its IP address.
No, entries in the hosts-file doesn't make your computer into a nameserver. They do however override the system lookup so that you don't have to use a name server for this.
c++;
I'd hardly call hosts files obscure...
Also, restricting name resolution to host file only does not "defacto limit the webservers that employees may visit" as this file is never consulted if the webserver is accessed via its IP address.
I'm pretty sure that's well known...
No sig today...
This is not well known, but every computer connected to the Internet is capable of being its own nameserver.
This is in fact fairly well known among the people who need to know these things. Also the hosts file is no substitute for DNS. It cannot, for example, give you MX records, cannot perform round-robin load balancing, and even if the sync of the hosts file is very quick, is not a suitable way to deal with the fact that name to ip mappings change frequently. Anyone who set things up as described above would be committing malpractice.
Someone had to do it.
This sounds like a denial-of-service flaw. Such flaws are considered "low severity" in all but the rarest cases. A high-severity flaw would be one which either gives a hacker control of a service or access to sensitive information.
This is just one more in a long list of well-known ways anyone could knock a server offline.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Hosts.txt isn't a well-known thing? I would categorize it as more of a known-but-inefficient thing, since you can typically do redirection and other stuff hosts.txt does at the firewall level, negating the need for some complex P2P setup.
High severity threats are those that either disclose sensitive information or allow unauthorized control of a service or system. Denial of service vulnerabilities are almost universally considered low severity. This is just one more in a long list of known ways to DoS a system.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Seriously? What companies avoid nameservers?
Why would you believe your P2P software is less prone to vulnerabilities than BIND?
Perhaps, If your company employs people who cannot type in an IP address. Nonetheless, I can think of many much better ways to limit employee internet access.
All software has vulnerabilities. If your nameserver has an issue, you upgrade BIND and you're done. If your P2P software on every desktop has a vulnerability, you now have to update software on every desktop. Assuming, that is, that the vulnerability is ever publicly disclosed.
Who could have foreseen such a problem in such modern and well-crafted software.
If corporations are people, aren't stockholders guilty of slavery?
This was bound to happen...
Also severely limits who you can send email to. And is excessively cumbersome. Easier to just run your own BIND and not allow connections from outside.
djbdns - if you want a secure one.
You can't handle the truth.
Hosts is old. It predates DNS, and is one of the reasons for DNS. DNS (and WINS, technically) were developed because maintenance of the hosts file across a network of computers is too complex. Updates would be slow, insecure, inconsistent and unreliable, particularly if you use DHCP on your network instead of static addressing (which everybody with a brain does on a non-trivial network). Cache poisoning would be a constant problem. Nevermind that all the hosts file does is translate names to IP addresses, while DNS does much more than that.
So, yes, if you're willing to sacrifice ease of administration, security, functionality, performance, and reliability, you can absolutely revert to distributed hosts files over DNS.
The road to tyranny has always been paved with claims of necessity.
Riiight... so you're saying we're better off using younger software than more mature software because, let me see if I got this right, your theory is that the new software has fewer bugs than the mature software?
Now, if you find PowerDNS has more features, easier to set up, what have you, that's fine - that's the purpose of new software attempting to displace old and not the topic here. It's not often that new software has fewer bugs (including security holes) than more mature software.
Most of what I see hosts files used for now is to "null route" (direct to 0.0.0.0) known bad hosts.
I do the same on my computers, but instead of "known bad" hosts I block various ad servers
Don't blame me, I voted for Kodos
Now I really wonder... are you someone totally incompetent trying to post as a windows admin or just an elaborate troll
Because I really don't see the point to try to push the usage of host files in this community (or any community, for that matter - especially as an alternative to DNS).
Yeah, a lot of anti-malware software does this. Spybot Search & Destroy adds about 15,000 entires to hosts that point to 127.0.0.1, which might fail safer than a null route. It amounts to the same thing.
The road to tyranny has always been paved with claims of necessity.
return to ARPAnet? Are you MAD?!?! replace the hierarchical DNS structure w/ P2P filesharing to avoid a vulnerability? Are you INSANE?!?! Sure, professional consultants may understand that alternatives exist for several key infrastructure services (oooh let's get rid of RIP/EIGRP/BGP/etc w/ static routes. It's more secure and that means its more reliable!). Hopefully they understand the issues w/ NOT utilizing it and the ramifications to operational costs to maintain it as well as the implications to reliability. End of the day... you're CRAZY!
I am not one of the ACs in this thread. That being said, I have some background and experience in network administration in environments from SOHO to global enterprises.
Now, please detail how you'd set up an automatic and redundant P2P distribution network for a HOSTS file including your mechanism for securely updating said HOSTS file from a location of your choosing, and explain how your solution is more efficient than your company's infrastructure's DNS systems. If you allow updates from anywhere other than a central location, what happens when malware on a personal computer alters the HOSTS file - does it cause an erroneous update to be pushed out to the group? Can you ever tell that the one computer is stale? Would you push the updates on demand only, or every X minutes/days?
You're clearly talking about a business use of some sort here. Have you done this in a business environment? How large? How did you convince them to allow you to override DNS with myriad HOSTS files? Have improvements in their network infrastructure superceded your solution, perhaps without your knowledge?
The only benefit to having a HOSTS file distribution like that might be that it could be distributed faster than your DNS can replicate changes via a push or pull mechanism, although in a modern enterprise environment DNS changes should be able to propagate in minutes if not seconds.
Once a system is removed from that HOSTS file distribution, or the distribution fails because a server dies or a network link is broken temporarily, or a user does something that causes their personal machine to stop receiving changes, then you have stale HOSTS files everywhere conflicting with your DNS. How do you propose to clean that mess up?
DNS should at least be set up such that (in no particular order):
1) It is very redundant (multi-homed) and thus robust/reliable
2) Administrators can control it and add/alter/remove records
3) Replication is fast
4) The source of changes can be verified or at least identified
5) Poisoned updates from the untrusted wilds can be rolled back and audited once they have been identified
How often do you have significant DNS bugs whose actual (not theoretical) impact and resolution outweighs the implementation cost (time and money) of your custom HOSTS distribution solution? I propose that this scenario does not exist, but someone has created this alternate solution "just in case" which just smacks of the 1980s rather than learning how to correctly administer their DNS infrastructure. Either that, or someone is upset because they weren't permitted to alter the corporate DNS the way they wanted / anonymously, and became the squeaky wheel and pitched their solution to execs in the business who don't know the difference between a CPU and a chassis. (Nor should they have to, it's not their job.) These are possibilities, perhaps not accurate. However: None of these are acceptable for a network administrator. All network admins should be seeking ways to improve their DNS setup, staying on top of the state of the art, and using HOSTS files *only* when appropriate.
HOSTS files do have uses.
* Null-routing a server that's been causing some isolated issue, such as an ad server or some other server that your software times out waiting for; Also, null-routing a server to prevent a new software package you're testing/developing from reaching a production server
* Rerouting a name to your local development environment while debugging or developing software
* Guarantee resolution of key server names on a portable demo workstation that often finds itself on different private networks
I think you need to chill out a little bit, regardless. There's entirely too much angry excitement in this thread, and there's a lot of arguments that seem to stem from personal experiences with isolated situations from the distant past that basically never happen in a properly configured environment, and don't cause the kind of disaster that they are imagined to cause. Let's try to stay calm, civil and professional on a public technology website.
Does anyone know which DNS servers are either derived from or just repackaged BIND? I haven't been able to find this information anywhere.
I addressed my post incorrectly. I was replying to the thread as a whole, which was not correctly conveyed.
Logon scripts that copy from where?
Still, it wouldn't kill you to be civil.
Ugh, there are some bored forum trolls and they are out in force today. It looks like they did a drive-by on our conversation. Either that, or someone involved in that forum happened across this. If you're trying to say it was me trying to discredit you... how do I know it wasn't you setting up that accusation? I don't know. Whatever the case, I don't especially care for it.
I followed those links and guess what I see there... if that's you, you tend to know what you're talking about, although you get more impassioned than other people might. (See, if you weren't posting AC, I might have been able to do that with your Slashdot comments.) Looks like the troll backfired, didn't it? If it's not you, they did an excellent job impersonating you and making you look good up to the end, and you should probably do some damage control. If it is you, then you should own up to your mistakes and move on.
All I ever wanted was to say "there are better ways to do what you guys are talking about than dumping hosts files everywhere" and see if you'd thought of something I hadn't, and I was hoping the person you were replying to would get on board as well. It's clear that you're not in this for an exchange of ideas, so I'm not going to participate any further in this thread that's devolving into a flame war / troll-a-thon. It's a shame when Slashdot turns into this sort of mess. Better luck next time!
Have you started looking for a newer wife?
(reference https://www.isc.org/software/bind/advisories/cve-2011-0414)
* As Larissa pointed out, this security advisory used ISC's phased disclosure process (see http://www.isc.org/security-vulnerability-disclosure-policy). The US CERT advisory stated they notified ISC on 2011-01-24. This is reversed. US CERT and all other National CSIRT Teams were notified at the same time (Feb 15th). We just recently added the step in our disclosure process to notify all National CSIRT Teams listed on first.org.
* US-CERT threw in the "2011-01-24" thinking the discovery of the vulnerability matched the time we asked for our next batch of CVE numbers. In this case, this vulnerability was discovered by Neustar, who found the initial defect, and JPRS, who built the feasible lab exploits. That was all in Feb 2011, not Jan 2011.
* The "high severity" is based on the CVSS _BASE_ Score of 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C). Network operators would use this CVSS base score and then run the Environmental and Temporal Score to get a CVSS actionable score. This is why you saw a low score from US CERT so low. They used their proprietary full metric, which scored it lower. Vendors are encouraged to use CVSS so the operator then takes accountability to gauge the risk specific to their environment.
Check out http://www.first.org/cvss/ for more information on CVSS. ISC has recently started using CVSS for all our security advisories (see http://www.isc.org/announcement/iscs-has-adopted-cvss-our-security-advisories).
* DNS Operational Risk and Reaction to any DNS issue is best addressed via DNS-OARC. If your DNS is critical, I recommend, as a minimum, to sign on to the public BIND forums (see https://lists.isc.org/mailman/listinfo) and the public DNS-OARC forums (see https://www.dns-oarc.net/oarc/services).
I don't know how many readers Slashdot has these days, but I bet many of them have one elbow on their desk and the palm of their hand on their forehead reading this. I really don't get your agenda either (assuming you are not the AC or in league with the AC that opened this particular topic...). You are simply stating the obvious, but also something utterly impractical in incompatible with the architecture of the Internet. And I'm not even getting started on the basic flaw of your suggested "alternative", which reside in the initial generation of the host file.
Am I aware of those things? Seriously?
If you do work in IT and are dealing with systems to sensitive to the point where doing DNS request is too risky, I would ask myself serious questions if I were you. Those systems should probably not be linked on the Internet in the first place.
I don't think it's worth the energy to debate... your mind is clearly set. But I will at least answer your question. By "alternative", I meant "alternative to the use of DNS" (understand, local host override). By "initial generation" I mean the generation of the host file (regardless if it's done by you or, worse, by someone else). You can't deny that domain name poisoning is really critical at this stage. You only need to have someone malicious having access to your host housekeeping scripts or to one of your "trusted" host file source and you opened him the door to a goldmine.