New DoS Vulnerability In All Versions of BIND 9 197
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."
Interesting (Score:2, Interesting)
This is very interesting. I'm sure the people behind BIND will scramble to get things sorted out ASAP, but I wonder how long it will take other vendors (Apple, I'm looking at you!) to release a patch.
I do have to wonder about exploits like this that seem initially incredibly serious, yet nothing much comes from them and they don't seem to get exploited to the extent that you might expect they would - this one reminds me of l0pht's famous claim that they can bring down the internet in 30 minutes. If this vul
Re: (Score:2, Informative)
Re: (Score:3, Interesting)
Re:Interesting (Score:5, Funny)
It is now.
This vulnerability also gives the three people running DJB DNS [cr.yp.to] a much needed opportunity for some smugness.
Re:Interesting (Score:5, Funny)
I was under the impression they had smugness to spare.
Smug (Score:4, Funny)
Great opportunity to vent some smugness today
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
" This is very interesting. I'm sure the people behind BIND will scramble to get things sorted out ASAP, but I wonder how long it will take other vendors (Apple, I'm looking at you!) to release a patch. "
I'd be less concerned about that than I would be about how long it will take for people to do something about this on their nameservers. IMO the best update to BIND is DJBDNS but that's just me.
Either way, there are FIVE HUNDRED THOUSAND nameservers out there. Some of them still run Bind 4.7.
Re: (Score:2)
Your post reads like you'll ask for $20 to show people how THEY TOO CAN SET UP A .HOSTS FILE.
Just saying.
Also, your approach is stupid because I like to use the internet.
Re: (Score:2)
" Your post reads like you'll ask for $20 to show people how THEY TOO CAN SET UP A .HOSTS FILE "
Still cheaper than a $35 domain from Verisign.
Re:It's because it works, & I believe in every (Score:5, Funny)
My approach isn't stupid in regards to that. Free? That's a "pretty good price", wouldn't YOU say? And, you're also FREE to customize it, & thus, YOUR PERSONALIZED VERSION OF A CUSTOM HOSTS FILE, JUST GOES ALONG WITH YOUR PERSONALIZED SPED UP & SAFER VERSION OF THE INTERNET... &, just as YOU see fit & like, easily. Notepad.exe for instance? My gosh - lol, just "does wonders" here, on this account... lol!
Are you the ghost of Billy Mays?
Re: (Score:2)
May I have your contact information? I would like to hire you next time I need to write a come-on for an item I'm trying to peddle :P
There's no place like 127.0.0.1 (click) There's no (Score:2)
Re:There's no place like 127.0.0.1 (click) There's (Score:2)
No it doesn't. Why do you lie ? .txt . You can open the existing hosts file by right clicking and selecting "open with" and then choose notepad. It doesn't append .txt to an existing file name.
/etc/hosts which is much quicker tha
If you create a new file it will append
I don't generally care anyway, as I can vi
Re: (Score:2)
Isn't 0.0.0.0 the broadcast address? Likely blocked by your router then. Comma si, comma sa.
It's generally in c:\windows\system32\drivers\etc
Re: (Score:2)
Is it faster for 0.0.0.0 to give you nothing or for 127.0.0.1 to give you a connection refused?
Comment removed (Score:4, Insightful)
Re: (Score:2)
You should really read up on data structures, using a hash map which I guess most DNS-servers use is a LOT faster than searching through a hosts file.
Re:I have my own "patch", called a HOSTS file... a (Score:2)
Any ISP's DNS that mucks about with NXDOMAIN is by definition not standard.
Re: (Score:2)
Just like I said in my post, I'm talking about ISPs (lookin at YOU charter...) that supply a malicious DNS server.
Re: (Score:2)
Use Unbound or NSD (Score:5, Informative)
Re:Use Unbound or NSD (Score:5, Informative)
Re: (Score:2)
for dns caching, dnsmasq is nice too, but I'm not certain that it has a good security history.
Re: (Score:2)
Google for: dnsmasq vulnerability
Re: (Score:3, Interesting)
PowerDns for the win. Plus it reads legacy BIND zone files.
Well.. (Score:2, Funny)
Well DNS operators do appear to be in a bit of a bind don't they?
Ain't what it used to be.... (Score:4, Interesting)
Was once the day whe a notice like this would kick off a flurry of migrationn plans, compiler scripting, compiling, and restarting servers in the dead of night. (and bonuses to match!)
But now?
# yum -y update && shutdown - r now
Sometimes I pine for the 'good old days'. A little. (ok, hardly at all)
Re: (Score:2)
Having said that patching in netbsd will require a compilation at my end. It would be nice if I could just update a package. The infrastructure is right there for it...
Re:Ain't what it used to be.... (Score:4, Informative)
You seem to be just taking all changes and rebooting. I do that all the time on my ubuntu laptops but I wouldn't manage my servers that way.
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.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
Re:Ain't what it used to be.... (Score:5, Informative)
I'm just hoping that CentOS pushes out the update before 10:00 PM MST today.
Why?
So I'll get my daily e-mail status update, telling me to do just that: run yum, and then restart (just bind) -- as opposed to seeing it tomorrow.
As a footnote, it is generally a good thing to subscribe to whichever vendor's security-announce list that you use. It is really nice getting e-mail notifications of security-related package updates. CentOS has one, right here: http://lists.centos.org/mailman/listinfo/centos-announce [centos.org]
Re:Ain't what it used to be.... (Score:5, Insightful)
Why in the holy hell would you reboot a server to put a new install of BIND into service?
Re:Ain't what it used to be.... (Score:5, Insightful)
Oh, wait, these are fellow Linux "admins" we're talking about...
Re: (Score:2)
The strange thing is that he used shutdown -r now instead of this newfangled reboot the kids like to type. If you know what shutdown does, you should know when to not use it.
Re: (Score:3, Funny)
Re:Ain't what it used to be.... (Score:4, Funny)
I never heard that one, but please tell me it stands for "Right Fucking Now."
Re: (Score:2)
That's not as funny.
Color me disappointed.
Re: (Score:3, Funny)
No need to restart bind after updating using yum (Score:3, Informative)
It gets restarted automatically. Check system.log.
Re: (Score:2)
Re: (Score:2)
Because modern-day admins don't know how to restart a service?
Oooh! Oooh! I think I can get this one! Either of these should work:
# service named restart; /etc/rc.d/init.d/named restart;
#
But... if you have a properly designed network, why the **** wouldn't you reboot your name server? Given that there are minimally TWO of them registered for your domain name, that the DNS protocol is designed to seamlessly fail over in the event of a failure, rebooting the name server will have no discernible effect for any
Re: (Score:2)
Assuming you have failover for other services running on your network (as you probably should if you're working in an organization that gives two rips about service availability), do you restart entire servers eac
Re: (Score:2)
Because modern-day admins don't know how to restart a service?
Oooh! Oooh! I think I can get this one! Either of these should work:
# service named restart; /etc/rc.d/init.d/named restart;
#
Properly designed packages do "service foo condrestart" on upgrade anyway, so most of the time you don't need to manually restart anything.
But... if you have a properly designed network, why the **** wouldn't you reboot your name server? Given that there are minimally TWO of them registered for your domain name, that the DNS protocol is designed to seamlessly fail over in the event of a failure, rebooting the name server will have no discernible effect for any end user,
I'm afraid you're wrong. If one of your DNS servers disappears, stuff will continue to work *slowly*. If you have 2 NS records then each server will get 50% of the requests. That means that 50% will go to the dead server and have to wait for a timeout before trying the working one.
There are other reasons for not rebooting - restarting bind takes approximately 2 second
Always do a reboot test ... (Score:4, Insightful)
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.
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Please tell which repository managed to mess up that badly, so I can steer away from it in the future.
Re: (Score:2, Insightful)
If you're running a serious server you should always do a reboot test after installing any software.
You should obviously wait to outside working hours in case it actually breaks something.
If you apply an update over ssh you should test that you can create a new ssh connection before you disconnect the first one.
Re: (Score:3, Insightful)
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.)
Re: (Score:2)
Re: (Score:2)
This isn't Windows...
# yum -y update named\* && service named restart
(Not sure if yum [or apt] would restart named and NOT willing to take the chance.)
Pray it comes back (Score:2)
# yum -y update && shutdown -r now
and pray to FSM that it comes back up.
All versions of Bind 9? (Score:3, Funny)
Good thing I'm using FreeDOS!
Re:All versions of Bind 9? (Score:5, Funny)
At least someone agrees that BIND 9 had issues... (Score:3, Interesting)
According to this document [ripe.net], BIND 9 has issues including being monolithic, having a "Bad Process Model", Hard to Administer and Hard to Hack. That's not a good reputation to have.
To some extent, these issues apply to everything Linux save for the last point. I am waiting for the time these points will not apply to Linux and its associated software.
I must say that understanding BIND's configuration file was not that easy for me at first but after trying several times, I can say I am almost an expert. Things can be made simpler though. A text based interactive system could be of a lot of help. Tools like Webmin come in handy too though they require that a system be running initially.
Re: (Score:2)
Not a very clever bit of trolling.
Re:At least someone agrees that BIND 9 had issues. (Score:5, Informative)
Recent versions of BIND (8+) are not terrible to administer, and have much more reasonable data files. Older version were *really* nasty, and had a data file format so complicated that we invented a dedicated zone-transfer mechanism just so people could send DNS data to each other.
And while djbdns uses an unconventional admin system with lots of environmental variables, that's a one-time setup (that is probably done in large part by your package manager) and the actual data files are dead-simple -- plain text, one record per line, can do DNS lookups at build time, can concatenate files, etc. There are valid complaints to be made about djbdns, but I don't think "difficult to wrangle" is one of them.
Re: (Score:3, Informative)
" Older version were *really* nasty, and had a data file format so complicated... "
Rememeber that this was a product of the early 1980s; Brian Reid, Director of Digital Equipment Corporation's Network Systems Laboratory ("decwrl.uucp") hired a kid, Paul Vixie, to take the buggy Berkley B-tree code and turn it into something resembling professional software. At the time even C was not even close to ubiquitous, Assembler was though and in fact the great majority of code written for the early microprocessor ba
Only effective against MASTERS... (Score:5, Informative)
From the advisory: "Receipt of a specially-crafted dynamic update message to a zone for which the server is the master may cause BIND 9 servers to exit. Testing indicates that the attack packet has to be formulated against a zone for which that machine is a master. Launching the attack against slave zones does not trigger the assert."...
So an obvious workaround is to only expose your slave DNS servers and to not expose your master server to the Internet. That's part of "best common practices" isn't it? You have one master and multiple slaves and you protect that master. Come on, this is pretty simple stuff. Just simple secure DNS practices should mitigate this. Yeah, if you haven't done it that way to begin with, you've got a mess on your hands converting and it's easier to patch. But patch AND fix your configuration.
Re: (Score:2)
That's part of "best common practices" isn't it?
Two posts up there is someone mentioning a reboot to solve this. Best practices seem like rocket science around here...
Re: (Score:2)
Hmm, both of my public servers are 'masters' because the zones are synced via rsync over SSH from an internal server which actually has the master copy of the zones. However as far as bind is concerned, they public-facing ones are masters.
I could potentially trick it into thinking it's a slave zone but seems too fiddly/risky, so I'll just wait for it to be patched. Nagios will tell me if they stop working, anyway.
Re: (Score:2)
Perhaps you should rethink that mistake and create a real "master" and make them "slaves". The system was designed this way for a reason. It baffles me why people do things this this way.
Re:Only effective against MASTERS... (Score:5, Insightful)
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.
Re: (Score:2)
Copying zone files over ssh means you then have to rndc reload/reconfig every time you change a single A record.
With a "normal" hidden master + slaves setup, at least you can send Notifies which will cause the slaves to query the master and update the zone without a reload. Also, this is the only sane way to provide secondary DNS for a trusted third party.
If you have a lot of zones, it can take a while to reload bind. If you only have a handful of zones, and you don't do secondary DNS, I'm sure reloading
Re: (Score:2)
There is no need to reload all zones. You can easily detect which zonefiles have changed since the last reload and do "rndc reload ".
Re: (Score:3, Informative)
As kju responded, you can reload on particular zones if you want. The logs seem to suggest that bind itself only actually reloads the zones which have changed (i.e. mtime is newer than the last time it was loaded). I only get messages that it's loading every zone if I actually restart bind (stop and start), telling it to reload I only get messages about zones that have actually been changed.
I haven't noticed any performance hit from doing a simple reload, but I only have 120 zones.
If we were supplying secon
Re: (Score:3, Informative)
So I'm responding not because I disagree with your conclusions, but I disagree with the logic you're using to justify them:
You start off with a reasonable statement (th
Re: (Score:2)
I do it that way mostly because I didn't previously consider "type master" to be a potential vulnerability (they don't have dynamic DNS or anything fancy enabled). Maybe it is time I looked into djbdns, now that it's no longer a pain in the ass to install.
As for not using the built-in zone transfer method, that's partly because I don't particularly like it, but mostly because I don't see any reason to allow access to our internal hosts from our DMZ unless absolutely necessary -- and this is not a case where
Re: (Score:2)
DNS queries are not encrypted, so if you believe the contents of your DNS zones should be secret, you'd better hope nobody queries them. You may be interested in TSIG, which can authenticate your secondaries to your master. If you'd prefer to store and manage your zone files "offline", pushing them out to one or more masters through SSH or something might be the right thing to do, but if you already have an internal master, and need to update some public-facing slaves/shadow masters, there's no reason to
Re: (Score:2)
Well the SSH is only used a convenient transport mechanism, with a nice side effect of some kind of authentication that the host it thinks its transferring the data to really is that host. But all the transfers happen through our internal network anyway, so it's not really important. The reason it's preferred is because the internal server connects to the DMZ server, rather than the other way around. We try to avoid letting DMZ hosts contact internal servers whenever possible, under the assumption that the
Re: (Score:2)
This [rfxn.com] might help too.
Master for "localhost"? (Score:2, Interesting)
You may hide your master DNS servers but your slaves are probably still master for "localhost".
For goodness sake upgrade.... (Score:5, Funny)
...to Windows! DOS is just so 80's and 90's it's not funny.
(Suggested mod: +1 funny)
Re: (Score:2)
Si, creo que tres o cuatro seria mucho mas moderno.
I' m apesadumbrado, no hablo español (solamente me utilice Babelfish)
Re: (Score:2, Funny)
djb (Score:5, Funny)
Somewhere I think djb [cr.yp.to] is managing to both smile and raise his eyebrows simultaneously.
Re: (Score:2)
came for the djb mention, leaving satisfied.
/ yes, I am.
Re: (Score:2)
Praise be to Dan and may peace be upon him.
Re: (Score:2)
I considered using djbdns until I stumbled across his inflammatory and borderline-fanatic [cr.yp.to] attitude against BIND. What the hell, man? It's just a DNS server. Get over it.
Re: (Score:2)
I use his software even though I do know that he has some strong opinions, and probably some ridiculously strong opinions. He's not a politician, it's clear.
The stuff is beautifully simple. Qmail too.
LDAP based Zone updates (Score:2)
This is a reason why I want to be able to do LDAP based zone updates.
Re: (Score:2)
How would that help with this? You don't even need dynamic updates enabled for this to be exploited.
Servers behind Firewalls (Score:3, Insightful)
Re: (Score:3, Insightful)
A server behind a firewall does not imply a server on a private network. You can have firewalls in front of a DMZ on a public address providing services. Firewalls are used for much more than merely "private networks". Those are two orthogonal issues.
OTOH... A master on a private network providing zone feeds to slaves on various other networks (firewalled or not) on public addresses would be a very good idea.
Re: (Score:2)
Please remember that most "private" networks aren't. They have laptop or VPN access to potentially compromised hosts, which may insert attacks from behind your typical firewalls. I've had considerable difficulty explaining this to management who have, effectively, been lied to for years by their own staff who refuse to accept responsibility for the existing insecure mess, and who are uninterested in the unglamorous and unpopular work of fixing it.
OMG... (Score:5, Interesting)
I reported a bug *very* similar to this back in Oct, and only now its coming to light? WTF? I submitted this back in january and it was rejected. Ah well. Here's my page on it: http://garion.tzo.com/resume/page2/bind.html [tzo.com]
iptables to the rescue (Score:5, Informative)
For a quick "fix":
iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'
Will block (all) dnsupdate requests.
Re: (Score:2)
Will CentOS 4 be updated? (Score:2)
Poor coding (Score:3, Interesting)
Why on earth is BIND shipping with assertions that cause the entire server to exit when they fail? They should just cause processing of the current request to exit.
Why not ? (Score:2)
Time to let go of that ancient rule that ports under 1024 are root-only.
Asserts... (Score:2)
And this is why asserts should *never* go into production builds of any project. It's fine to have asserts in your debug build, but ALWAYS deal with the unexpected case immediately after your assert (which should be compiled out in release mode).
If you have no way of throwing an error and handling it gracefully back up your call stack (no, you don't always need exceptions for this), then you've done a shit job!
who cares... (Score:2)
Re:god they should learn programming (Score:4, Insightful)
Re: (Score:3, Informative)
Re: (Score:2)
Only a fool would configure public-facing DNS servers as masters
At a minimum you're going to be 'type master' for localhosts forward and reverse and broadcast zones as per rfc1912. You're also going to be master for rfc1918 space if it's a recursive name server. The word 'master' in the context of this bug is the bind configuration option 'type master', present in ?all? bind configurations, not the name server that controls updates to others.