Slashdot Mirror
New DoS Vulnerability In All Versions of BIND 9
Icemaann writes "ISC is reporting that a new, remotely exploitable vulnerability has been found in all versions of BIND 9. A specially crafted dynamic update packet will make BIND die with an assertion error. There is an exploit in the wild and there are no access control workarounds. Red Hat claims that the exploit does not affect BIND servers that do not allow dynamic updates, but the ISC post refutes that. This is a high-priority vulnerability and DNS operators will want to upgrade BIND to the latest patch level."
Why in the holy hell would you reboot a server to put a new install of BIND into service?
Because modern-day admins don't know how to restart a service?
Oh, wait, these are fellow Linux "admins" we're talking about...
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
It's unlikely that, if you're running a DNS server inside of your private network, someone on the outside is going to be able to hit it. But then, like all other vulnerabilities, you combine this one with a couple of other attacks (such as a non-privileged login), and all of the sudden you've got something really dangerous. :-(
Your Servant, B. Baggins
If you're running a serious server you should always do a reboot test after installing any software. I've been burned many times by someone doing a "harmless" installation only to find out 6 months later a critical library was upgraded with an incompatible one (a recent example is expat 2.0) and the server doesn't boot like it should.
Always reboot! Even with the super slow bios you get in servers nowadays it should only take 2 minutes to be back up and running.
Because lots of people don't want intruders being able to affect the actual zone data in case an outward-facing DNS server gets compromised. Using SSH to transfer zone data is much easier and more secure than BIND's own zone transfer mechanisms (e.g., you can automate and schedule them), and you don't have to worry about zone transfers through firewalls. Troubleshooting all the weird crap that can happen between different DNS daemons all supposedly doing regular AXFRs is a real pain in the ass. SSH makes life easier.
If having a DNS machine on the Internet that thinks it is a master really is a mistake, when then, BIND9 is a piece of shit. This is the most straightforward thing a DNS daemon should be asked to do.
Nowhere in BIND's manual does it say people have to use BIND in a master/slave setup.
Because you may have a stack of other pending updates, particularly kernels, and this has been the first "gotta switch" update in quite some time for those core servers? Also because without the occasional reboot under scheduled maintenance, it's hard to be sure your machines will come up in a disaster. (I've had some gross screwups in init scripts and kernels cause that.)
Sounds like a lot of work when you can just run Treewalk DNS and be done with it.It is fast, uses very little resources (mine is using 5Mb ATM) and never gives a bit of trouble.
ACs don't waste your time replying, your posts are never seen by me.
It could have been worse (and no, I haven't read the article yet). Failing an assertion means that they actually wrote an assertion that did it's job. It's impossible to know without reading the code, but this might have been a remote code execution exploit if they hadn't.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
More so because some package managers (such as CentOS) tend to replace customized init.d files with the stock ones (renaming the ones you had). This is not really a big deal, but it sometimes breaks some services.
If you are modifying packaged files that aren't marked as %config in the RPM spec then you're doing it wrong. 99% of the time you don't need to modify those files anyway, the other 1% of the time you really should be building a custom package and adding it to yum's exclude list.
http://blog.nexusuk.org