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 "
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
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.
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.
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?
Thankfully, yes, err, well, as far as they know at that time. I don't do IXFR on my authoritative or resolving bind servers so I simply don't care. Kind of hard to cause a deadlock during a tiny slice of a time in a process I don't run...
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?
Uh, no. At least not directly. According to
http://www.isc.org/software/bind/advisories/cve-2011-0414
the server simply stops responding. Usually deadlocks in any software freeze it up quite well rather than false data. Old data, maybe, at worst...
What happens to the rest of your security infrastructure when it stops getting DNS responses? Probably nothing, but someone whom tried really hard could make something like a syslog that wouldn't log if it cant log reverse DNS, so I guess you could brute force something while no one is watching, that is vulnerable to brute forcing (no rate limiting, weak enough to be brute forced, etc). Once they have access maybe they could set up some sort of spoofy thing.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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).
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.
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.
if you want a secure one.
If you want it to be really secure, you'd just turn the server off. If you want secure and functional, isn't even an option.
I'll say it: djbdns is the least secure popular DNS daemon. Its fatal flaw is that it only implements the easiest parts of DNS. Maybe it's exceedingly secure at handling that stuff. Who knows? Who cares? It leaves all the hard part of DNS administration to be re-implemented at every single site. For example, to the best of my knowledge, djbdns still doesn't implement IXFRs. The security vulnerability:
BIND method for dynamic DNS
djbdns method for dynamic DNS
djbdns pretends to be secure by ignoring all the things that make DNS "interesting". That's like writing a computer language with one instruction - say "subtract, branch negative", making that one instruction very robust, then making fun of people who use "insecure languages" (which happens to be everything but yours, as you loudly explain to everyone who will listen). No thanks.
Dewey, what part of this looks like authorities should be involved?