×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Potential 0-Day Vulnerability For BIND 9

Soulskill posted more than 2 years ago | from the bind-your-own-business dept.

Networking 187

Morty writes "BIND, the popular DNS server software, has been crashing all over the Internet. The root cause is believed to be a 0-day vulnerability in BIND's resolver. The ISC has issued an alert. Quoting: 'An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached. At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

187 comments

To the Red Phone! (4, Funny)

Anonymous Coward | more than 2 years ago | (#38085314)

Alert DJB at once!

10 years ago (4, Informative)

ghn (2469034) | more than 2 years ago | (#38085324)

I had to choose which DNS server I would deploy on my servers. I went for TinyDNS as it had all the same features and security promises. Man am I glad to have considered security over popularity.

Re:10 years ago (4, Informative)

Compaqt (1758360) | more than 2 years ago | (#38085410)

Another small DNS server is MaraDNS. It's considered a good alternative to BIND [google.com] .

Being a lot smaller, it's easier to secure.

If you're just running a DNS cache on your desktop, check out dnsmasq. Click to install [deb] (Deb/Mint/Ubuntu)

Re:10 years ago (1)

swalve (1980968) | more than 2 years ago | (#38086148)

Agreeing with dnsmasq. Bit of a bitch to set up just right, but I've got it working now running my firewall/router.

etckeeper (5, Informative)

Compaqt (1758360) | more than 2 years ago | (#38086364)

By the way, another thing people who are wont to mess with their /etc should keep in mind is etckeeper. It versions your /etc, by default in bazaar, but it's also supposed to work with git, hg, etc. It has triggers set so every time you install something, it does an automatic checkin.

You can also manual commits, too, along with a message.

Good for people who want to know what the config files looked like when they were working a week ago.

Click to install [deb] (Debian and friends)

Re:etckeeper (0)

Anonymous Coward | more than 2 years ago | (#38086460)

Wow, thanks for this, I had no idea that kind of software existed! I don't dabble that much in /etc, but this looks like a nice security.

Re:etckeeper (3, Interesting)

X0563511 (793323) | more than 2 years ago | (#38086978)

Awesome!!

I've been known to keep subdirectories of /etc as SVN repository checkouts, but that grabs the whole thing!

The only thing I'd be worried about is accidentally uploading sensitive data (hashes and such).

Re:10 years ago (1)

gmack (197796) | more than 2 years ago | (#38086682)

Better yet use Unbound resolving only nameserver since it supports signed zones.

Re:10 years ago (0)

Anonymous Coward | more than 2 years ago | (#38086906)

unbound is very nice for recursive DNS too.

many more features than djb, and currently maintained.

Mara had scalability issues in its recursive code (separate thread per query), which made it unsuitable for large installations. Yes, there is now a version to address this, but it wasn't stable when we swapped out djb.

Re:10 years ago (3, Funny)

janeuner (815461) | more than 2 years ago | (#38085430)

It's hard to go wrong with DJB*.

Re:10 years ago (4, Funny)

afidel (530433) | more than 2 years ago | (#38085510)

Unless you have to actually work with him.

Re:10 years ago (1)

X0563511 (793323) | more than 2 years ago | (#38086986)

Glad to know I'm not the only one who thinks DJB makes no sense at all. Every time I see it it takes me half a freaking hour to figure out how to update a zone.

Re:10 years ago (0)

Anonymous Coward | more than 2 years ago | (#38088006)

Sorry to hear that you aren't flexible enough to handle different kinds of software. I'm able to change A records in tinydns zones in seconds, just like I can do in BIND and Microsoft DNS.

Re:10 years ago (1)

Onymous Coward (97719) | more than 2 years ago | (#38088250)

I think GP was referring to how inflexible DJB the person can be. But certainly their comment could be used to refer to the software as well.

Not only did DJB reject the design and development practices that left BIND such a threat but he also rejected a number of usual conventions around software management/installation/licensing. In his defense, he did it because he believed the conventions were bad. His own version of things makes sense and works well, but it's definitely weird if you're coming new to it.

Re:10 years ago (1)

Compaqt (1758360) | more than 2 years ago | (#38085576)

Wasn't there some sort of license problem with DJB stuff? Like the slowness of Java applets in the early 1990s, I don't think Slashdotters will let him live that down.

Re:10 years ago (1)

19thNervousBreakdown (768619) | more than 2 years ago | (#38085634)

I don't know about his DNS server, but qmail had some goofy license that meant everything was just a series of patches.

He's since released it into the public domain though.

Re:10 years ago (1)

Anonymous Coward | more than 2 years ago | (#38085920)

He had no license, believing that having no license and no copyright meant it was in the public domain. US law says otherwise, and DJB disagreed. Unfortunately, that put the software in limbo.

Eventually, a license permitting distribution of unmodified source was added. This, of course, meant compiled versions and built-in tweaks to make it work with certain compilers (like GCC) and distributions were not permitted to be distributed. Patches were granted as an exception. Distributors were too lazy to build an auto-patch system.

So, eventually DJB just decided, fuck it, here, just do whatever you like with it and that he'd comply with US law.

Re:10 years ago (0)

Anonymous Coward | more than 2 years ago | (#38086134)

what the fuck are you talking about "comply with US law"? no reason at all anyone involved needs to have license headers in those stupid source files.

Re:10 years ago (2)

powdered toast dude (800543) | more than 2 years ago | (#38087822)

My understanding was while that he permitted source redistribution, he insisted that it be only distributed unmodified, and never binary distribution. He also generally refused to accept patches, apparently thinking his pristine work ought to be good enough for everyone. (It was good, but needed features as time went on.) This meant that any "improvements" could only be distributed as patches. As a result, only source-based distros had an easy time packaging it, since sources + patches + build instructions is how they do business anyway. Having no friends with the binary distros, it got little distribution. It also languished on the vine since no one could push improvements upstream. Apparently he subsequently released both qmail and djbdns into full public domain, which means in theory they could be packaged and distributed normally now. Unfortunately, it seems too late for it to matter.

Re:10 years ago (4, Informative)

gmack (197796) | more than 2 years ago | (#38086934)

The major problem with Qmail was it's design simply didn't take into account the possibility of a bad return address. The downside was that it couldn't bounce during reception and so was forced to generate a bounce message instead and not only did spammers plug up the queue with bad messages, it ended up being used for reflector attacks where the attacker set the target's address as the return and sent messages that would bounce to many different servers. The whole problem ended up being so bad that many that many mail admins considered servers running Qmail to be almost as bad as an open relay and there were people who actually maintained blacklists of servers running Qmail and that was right about when I stopped using it but I hear there have been patches to fix the worst of it's flaws since then.

In short: it was secure for only some definitions of secure and for everything else DJB ignored the problem.

Re:10 years ago (0)

Anonymous Coward | more than 2 years ago | (#38087074)

The downside was that it couldn't bounce during reception and so was forced to generate a bounce message instead

What you describe is a general drawback for reliable mail delivery: either the mail gets through, or it doesn't. That it didn't do recipient checking at RCPT time is a tradeoff made to make qmail secure and modular and to best implement per-user extension addressing.

qmail isn't alone in this: Godaddy's custom MTA does the exact same thing.

and not only did spammers plug up the queue with bad messages, it ended up being used for reflector attacks where the attacker set the target's address as the return and sent messages that would bounce to many different servers.

Theoretically, that is possible. In practice I haven't seen spammers use that mechanism.

The whole problem ended up being so bad that many that many mail admins considered servers running Qmail to be almost as bad as an open relay and there were people who actually maintained blacklists of servers running Qmail and that was right about when I stopped using it but I hear there have been patches to fix the worst of it's flaws since then.

A lot of people are irrationally against djb in any way. He's become like the president, every time something goes wrong people blame him. Those blacklists you speak of are less about addressing an operational problem and much more about irrational dick waving.

Re:10 years ago (3, Insightful)

gmack (197796) | more than 2 years ago | (#38087558)

and not only did spammers plug up the queue with bad messages, it ended up being used for reflector attacks where the attacker set the target's address as the return and sent messages that would bounce to many different servers.

Theoretically, that is possible. In practice I haven't seen spammers use that mechanism.

I used to run qmail and I have seen it used for that.

The whole problem ended up being so bad that many that many mail admins considered servers running Qmail to be almost as bad as an open relay and there were people who actually maintained blacklists of servers running Qmail and that was right about when I stopped using it but I hear there have been patches to fix the worst of it's flaws since then.

A lot of people are irrationally against djb in any way. He's become like the president, every time something goes wrong people blame him. Those blacklists you speak of are less about addressing an operational problem and much more about irrational dick waving.

It's not irrational if you observe a problem only to be ignored. As I said earlier I used to run Qmail and I did so because of it's security benefits and while Qmail didn't get my box rooted the same way sendmail did, it still had it's problems. I have since moved to postifx and now have a que of 0 to 10 messages instead of the 300 to 1000 I had under Qmail despite the fact that I have 3x the number of domains and 5x the number of messages than I did before.

Re:10 years ago (0)

Anonymous Coward | more than 2 years ago | (#38088238)

I used to run qmail and I have seen it used for that.

Logs and specifics? Every time I push, it always ends up being vague generalizations, or FOAF anecdotes, or cargo cult sysadmin wives tales.

I'm not denying that it isn't a possible attack vector, but it certainly makes a clumsy one, and in my experience I haven't seen people use my qmail servers to attack someone like that.

It's not irrational if you observe a problem only to be ignored.

A lot of well known open source developers have routinely "ignored" "problems" when what was happening was the result of a perfectly acceptable tradeoff. Yet djb gets a disproportionate amount of ire. Look at how this slashdot post about a BIND problem quickly turned into an occupy-djb's-e-lawn movement.

I have since moved to postifx and now have a que of 0 to 10 messages instead of the 300 to 1000 I had under Qmail despite the fact that I have 3x the number of domains and 5x the number of messages than I did before.

Doubtless that has to do with other configuration tweaks in the meantime.

Note that I am not using qmail much these days (Exchange now "handles" most of our mail needs, much to my grief), so I am not trying to be a fanboi, but I am trying to add some perspective.

Re:But, BIND goes to, 11! (0)

Anonymous Coward | more than 2 years ago | (#38085672)

However, BIND supports Response Policy Zones! Does TinyDNS support THAT? Without this critical capability, the entire internet is open to compromise, people could accidently visit evil hostnames! All Hail Vixie!!

Re:10 years ago (5, Informative)

Above (100351) | more than 2 years ago | (#38085800)

This particular vulnerability applies only to BIND9 operating as a recursive resolver. BIND9 operating in authoritative mode, similar to how TinyDNS operates, is unaffected. Had you properly deployed BIND9 for the same purposes you are using TinyDNS you would not had been impacted by this issue.

Re:10 years ago (1)

ghn (2469034) | more than 2 years ago | (#38086782)

I was referring to DJBDNS in general and not just the authoritative TinyDNS program. I was also speaking of BIND's security history in general, not only this specific issues.

Re:10 years ago (0)

Anonymous Coward | more than 2 years ago | (#38087578)

Here is a link to an earlier exploit and BIND config changes which should have pushed most towards disabling unrestricted access to DNS recursion.
http://security.freebsd.org/advisories/FreeBSD-SA-08:06.bind.asc

Note -
If you run a mail daemon on the same system as BIND then you'll also want to add localhost (127.0.0.1) to the ACL list of allowed hosts. Otherwise it will reject mail with "Domain of sender address ... does not exist". You can test this by doing "nslookup -type=mx google.com" and it should return a valid, non-authoritative answer instead of : Can't find google.com.

NSD (3, Informative)

powdered toast dude (800543) | more than 2 years ago | (#38087694)

As a long-time BIND hater, I recently switched from djbdns/tinydns to NSD. I figured if it's good enough for a few root servers it was worth a look. It's very efficient and fast, uses standard zone files, fully ipv4/ipv6 dual-stack transparent, and is DNSSEC aware. Very pleased so far.

Impossible! (-1, Flamebait)

Anonymous Coward | more than 2 years ago | (#38085332)

It's open source, and has had years to mature...so many eyes on it that this couldn't possibly happen.

Right?

Re:Impossible! (-1)

Anonymous Coward | more than 2 years ago | (#38085432)

Yep, that is what the zealots always claim. Bet we don't hear any 'the developers must be held liable' crap either.

Re:Impossible! (-1)

Anonymous Coward | more than 2 years ago | (#38085458)

They should. Why not? Are they "engineers" or just digital carpenters?

Re:Impossible! (0)

Anonymous Coward | more than 2 years ago | (#38085566)

Devlopers should be liable up to the amount they charged you for the code, ie if the code fails to perform they have to give you a refund. It's wrong to demand payment for a product that doesn't work as it should (ie its broken).

Bind is given away free, and thus even if it fails, you've not paid for a broken product.

Re:Impossible! (0)

Anonymous Coward | more than 2 years ago | (#38085622)

Funny, that is not the argument given whenever there is a problem with closed source. Then it is always 'the developers should be liable for any damages caused by the bug'.

Re:Impossible! (5, Insightful)

1s44c (552956) | more than 2 years ago | (#38085446)

It's open source, and has had years to mature...so many eyes on it that this couldn't possibly happen.

We don't even know what is happening yet. Maybe it's just a DOS, maybe it's a potential exploit. What we do know is that no-one has any need to put recursive DNS servers on the internet unless they are running an ISP or a DNS service.

Re:Impossible! (0, Redundant)

Desler (1608317) | more than 2 years ago | (#38085518)

Although we do know that if this was in a Microsoft product you wouldn't be making such an excuse.

Re:Impossible! (0)

1s44c (552956) | more than 2 years ago | (#38085606)

Although we do know that if this was in a Microsoft product you wouldn't be making such an excuse.

No excuse. This is a disaster and I'm not excusing it. However it doesn't affect most people who setup their systems right. ISPs, DNS service providers, and anyone who has to let random strangers on their network may well be in trouble with this.

Of course if this was Microsoft it would no doubt be an easy remote execution of arbitary code but only crazy people trust windows with something as critical as DNS in the first place.

Re:Impossible! (0)

Anonymous Coward | more than 2 years ago | (#38086288)

Because Microsoft is a monopolist? This reason alone is sufficient to treat them very differently than anyone else, especially a community effort.

Re:Impossible! (0)

Anonymous Coward | more than 2 years ago | (#38085790)

What we do know is that no-one has any need to put recursive DNS servers on the internet unless they are running an ISP or a DNS service

But the advisory talks of an "as yet unidentified network event", which implies the cause is as yet unknown. How can you be certain that only public recursive servers are vulnerable? FTFA, I don't even have enough information to know whether this is caused by a malformed query or a malformed response packet.

So, what do you know that the summary is not sharing?

Re:Impossible! (1)

afidel (530433) | more than 2 years ago | (#38085860)

Except anyone with a resolver running BIND is potentially affected since all the attacker needs to do is point you at the invalid domain twice, that could be as simple as a webpage with the domain included and a meta refresh longer than the TTL on the domain.

Re:Impossible! (2)

Nerdfest (867930) | more than 2 years ago | (#38085528)

Of course it can happen, it's just less likely to have problems than software with only a few sets of eyes on it. In addition, I had patches installed on my linux machines this morning, before I was even aware the problem existed. How's that for turnaround.

News for mac fags (-1)

Anonymous Coward | more than 2 years ago | (#38085336)

Today's slashdot reader don't want to read about opensource stuff. They're all mac fags, and want to read about the latest way they're gonna get shafted, and love it.

Open sores == fail (-1)

Anonymous Coward | more than 2 years ago | (#38085474)

Open sores software == fail. Once again full of security holes that the "many eyes" failed to spot.

Re:Open sores == fail (5, Insightful)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#38085596)

I can see this is going to be a long thread full of trolls about open source, but the fact of the matter is that an application "crashing" (really ABENDing) due to an assertion failure is actually a sign of software doing what it was designed to do. Assert statements are used to check for "impossible" conditions, and have the program scream and die if one is found. So what we have here is a careful programmer's backstop doing its job.

Re:Open sores == fail (1)

bws111 (1216812) | more than 2 years ago | (#38085682)

I am confused - which was it designed to do: allow invalid data in the cache, or die when it found said invalid data in the cache? One or the other of those is a bug, not a design choice.

Re:Open sores == fail (3, Insightful)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#38085934)

I guess it's really a question of design philosophy. Microsoft has always been from the "never test for an error condition you don't know how to handle" school, leading to lots and lots of buffer overrun type problems or just plain application crashes. The other side is to have tests you "really don't need". Say for example you have a switch statement where you "just know" (have verified elsewhere/input comes from a trusted source, etc.) that you have a lower-case letter that you want to process, so the code ends up looking something like:

switch (c)
{
case 'a': whatever('a'); break;
case 'b': whatever('b'); break;
...
case 'z': whatever('z'); break;

default: // AND THIS IS THE IMPORTANT BIT
assert("c is not a letter!!");
}

Microsoft code would typically leave out the assert, and happily stumble along. At least with the assert, you know what AND WHERE the Bad Thing (TM) happened, and have a clue as to where to look to fix it.

Re:Open sores == fail (3)

bws111 (1216812) | more than 2 years ago | (#38086274)

First, this has nothing to do with Microsoft, so there is no need to drag them into it.

Second, I am not questioning the need to test for errors, or that sometimes the correct thing to do when an error is encountered is die. I am challenging your position that overall the software is doing what it was designed to do and this is not a bug. The assertion itself is fine - there are reasons why the cache may have been corrupted and you want to kill the program (hardware error, tampering with files, etc). However, in this case the check should have been done BEFORE the data was put into the cache, when the correct response would have been to simply reject the message. Failure to do that check is a bug.

Re:Open sores == fail (1)

bws111 (1216812) | more than 2 years ago | (#38086360)

Also, note that in this case the assert did NOT tell them 'where the bad thing happened'. If it did, it would not be 'an as-yet unidentified network event'. The assert, in this case, is simply saying 'at some point in the past a bad thing happened, and I just figured that out now'.

Re:Open sores == fail (1)

swalve (1980968) | more than 2 years ago | (#38086368)

Instead of testing for known and unknown invalid data, it's the right way to test for valid data and puke on invalid data? In your code example, you wouldn't need to run that test because you already tested/trusted it somewhere else. If you know it is a lower case letter, the test isn't necessary. Data should be sanitized before it ever gets to your logic.

Re:Open sores == fail (2)

1s44c (552956) | more than 2 years ago | (#38085630)

Open sores software == fail. Once again full of security holes that the "many eyes" failed to spot.

Unlike windows which never has remote crashes or remote execution of arbitary code problems. Tell me does microsoft.com still block ping? Why is that again?

Re:Open sores == fail (1)

X0563511 (793323) | more than 2 years ago | (#38087050)

Hilarity ensues [netcraft.com] :P

I'm joking though... because that's just one tiny piece. The rest of the infrastructure is indeed eating it's own dogfood - either directly, or via "citrix netscaler"

A confusing summary on /., let me try to do better (5, Informative)

Above (100351) | more than 2 years ago | (#38085572)

BIND [isc.org] is written by Internet Systems Consortium [isc.org] aka ISC, a non-profit that does various public benefit things for the Internet. The summary links to an alert from the Internet Storm Center [sans.edu] aka ISC, a project of the SANS Technology Institute [sans.edu] . There is no relation between these two ISC's, in this case the first authors the software, and the second tracks vulnerabilities. I'm sure by using a link to SANS many people on /. who are not familiar with these two ISC's will get them confused.

The link in the summary also goes to a preliminary version of the advisory. The correct, full summary is available on Internet Systems Consortium's web site as CVE-2011-4313 [isc.org] .

I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something, and that is used by bad-actors before the vendor is aware and able to fix the issue. In this case the bug simply crashes the server; there's no remote root or other exploit, and at this time there is no evidence of bad-actors using this bug at all. Rather it appears something interesting (unusual, perhaps put there intentionally) appeared in the DNS, and it triggered a bug in the software.

Some historical context may help. BIND8, for those who used it, was a pile of poo. It had a huge number of security issues and other problems and was generally a nightmare for sysadmins. Many people stayed on BIND 4.9.x for a very long time because of the issues in BIND8. When ISC launched BIND9, they wanted to change this perception. The action relevant to this bug is that BIND9 was designed to be full of assertions and other checks in the code. The goal was to catch any badness early, and if it was uncorrectable crash in a predictable way. The thought was that crashing with a core dump where you can fix the problem is far better than running off with bad data that could eventually be used in some sort of remote-root exploit.

This issue is sort of the payoff of that philosophy. Rather than taking this bad data and giving a remote hacker access to the machine BIND9 caught it with an assert, logs a useful message and core dumps. This is a big part of why 0-day leaves the wrong impression with me, "denial of service vector" seems to perhaps be a more accurate description. Sure, we could have a lively debate about if crashing is preferred or not, but I think most of the administrators who lived through BIND8 prefer the BIND9 procedures.

Internet Software Consortium also offers support [isc.org] for BIND (and DHCP). I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.

Re:A confusing summary on /., let me try to do bet (3, Funny)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#38085716)

BIND8, for those who used it, was a pile of poo.

Your understated discretion just takes my breath away.

Re:A confusing summary on /., let me try to do bet (1)

Jose (15075) | more than 2 years ago | (#38087194)

when ever I think of BIND8, I think of my .sig:

Re:A confusing summary on /., let me try to do bet (2)

Culture20 (968837) | more than 2 years ago | (#38085734)

I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something,

Something like cause a denial of service?

Re:A confusing summary on /., let me try to do bet (3, Interesting)

TheCarp (96830) | more than 2 years ago | (#38085846)

yes yes, but thats very limited. Yes, you can deny service.... but it can be started back up. The only loss is availability of the service, the integrity of the service is uncompromised. It isn't allowing someone to make you serve up their data, it isn't allowing anyone to dump data they shouldn't have, it isn't allowing them to change, erase or anything your data.

Essentially... a DDOS means you are hosed until they stop or you can upgrade... the term 0-Day tends to be used to refer to actualy security issues, where the denial of the service is the least of your worries. Patching isn't good enough because, they got a window in, and could have installed a root kit.

Re:A confusing summary on /., let me try to do bet (0)

Anonymous Coward | more than 2 years ago | (#38087214)

There's a reason it's called the CIA triad... 0-day has no implications what so ever about the impact, just that a vulnerability was unknown to the vendor or researchers is being exploited in the wild.

Re:A confusing summary on /., let me try to do bet (0)

Anonymous Coward | more than 2 years ago | (#38085964)

I also think the characterization as a "0-day" isn't quite right. To me at least a 0-day issue is a bug that can exploited to do something,

Something like cause a denial of service?

The same can be done via a flood of packets that saturate either the machine (CPU) or the network to the machine.

A DoS is unfortunate and annoying, but a bug that leads to a ("clean") crash is in no way the same as an exploit. Heck, after an exploit it could be possible for the attacker to restart the service so the victim does not lose service (and thus is less likely to know that something occurred).

Re:A confusing summary on /., let me try to do bet (1)

UnknowingFool (672806) | more than 2 years ago | (#38086870)

The point you are missing is "0-day" has come to mean vulnerabilities that can be exploited now for things like remote code execution, takeover, etc . In this case, the bug causes crashes but it is not clear that it makes the computer vulnerable to other security matters.

Re:A confusing summary on /., let me try to do bet (0)

Anonymous Coward | more than 2 years ago | (#38087310)

The point you are missing is "0-day" has come to mean . . .

Actually, the best I can tell is 0-day has become so trendy it has no meaning at all. I'd prefer if people simply stopped using it. It provides me with zero information.

Re:A confusing summary on /., let me try to do bet (0)

Anonymous Coward | more than 2 years ago | (#38087426)

Well, how about this:

We learned about the issue because BIND developers elected to make BIND crash whenever something was wrong. Let's follow the logic that the crash was caused by something in some random zone, that all this resolvers looked up and choked upon. What if other nameservers are being compromised as we speak, because their designers elected to either run with bad data or not to try to detect bad data at all?

Re:A confusing summary on /., let me try to do bet (5, Interesting)

surgen (1145449) | more than 2 years ago | (#38085906)

Thanks for the clear explanation.

If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor.

Very true. Its funny, that this morning I had applied security patches to a debian stable box and thought "hmm, looks like BIND is getting fixed, wonder what thats about" before this even got posted to slashdot.

Re:A confusing summary on /., let me try to do bet (1)

jakeguffey (587607) | more than 2 years ago | (#38085954)

I am 100% with you up until you say, "I'm amazed how many people run large, production name servers on BIND yet don't have a cheap support contract. If you run BIND, rather than getting your alerts via /. look into a support contract so you get them directly from the vendor." I have a couple issues with this. The first is simply that it's perfectly reasonable to expect a good UNIX admin to handle BIND without issue for generalist deployments. The other issue I have is that you don't need a support contract to get these alerts. Sign up for the bind-announce mailing list (link: https://lists.isc.org/mailman/listinfo/bind-announce [isc.org] ). Again, I'm totally with you up until the end there.

Re:A confusing summary on /., let me try to do bet (2)

Above (100351) | more than 2 years ago | (#38086328)

I'm not sure how to square large production name servers with "generalist deployments". Clearly the small admin can do without a support contract. However I've seen large ISP's, supplying service to millions of customers with no support, and I think that's insane.

If you go back to ISC's Software Support [isc.org] page you'll notice "Advance Security Notifications". Depending on the nature of the issue, ISC's support customers often receive notification before BIND-announce. I believe this particular issue went out in all forums pretty much at the same time due to the severity, but lesser issues may be released in a staged fashion.

Re:A confusing summary on /., let me try to do bet (1)

jakeguffey (587607) | more than 2 years ago | (#38086604)

Ahh. Point. I didn't realize that ISC support provided notifications in advance.

Re:A confusing summary on /., let me try to do bet (0)

Anonymous Coward | more than 2 years ago | (#38086008)

You would have to be a moron to run BIND for anything in the first place.

BIND the epitome of taking what should be a simple piece of software and turning it into an over-complicated, impossible to secure, impossible to debug, spaghetti coded piece of shit.

I mean BIND has been around for DECADES and there are still security vulnerabilities found all the time.

Re:A confusing summary on /., let me try to do bet (1)

Anonymous Coward | more than 2 years ago | (#38086192)

Yeah, but only the sheer incompetence a multi-billion dollar corporation like Microsoft could produce the level of spectacular FAIL needed to let the following kind of vulnerability go unaddressed for DECADES..

http://www.kb.cert.org/vuls/id/951982
Microsoft Windows UDP packet parsing vulnerability

You have to admit being able to get root by sending malicious packets to a CLOSED port on a machine is just so awesomely FAIL, BIND's little DOS exploit pales in comparison.

Re:A confusing summary on /., let me try to do bet (1)

Canazza (1428553) | more than 2 years ago | (#38086666)

that link you posted says it was patched 2 weeks ago. It makes no mention of the date the exploit was found. How do you know this was part of the software for decades?

Re:A confusing summary on /., let me try to do bet (0)

Anonymous Coward | more than 2 years ago | (#38086516)

I also think the characterization as a "0-day" isn't quite right.

Download Bind by Specific Version [isc.org] shows 9 was released 2004-Jan-28 07:05:51.

0-day used to mean that the exploit was release the day of release. Verses 1-day or later cracks.

Now it's just another throwaway term for exploit. And a very silly one at that.

(To be fair, it could be a problem with the last release from November 9th, 2011. I did not regression test this.)

meaning of zero-day (1)

Onymous Coward (97719) | more than 2 years ago | (#38087934)

0-day used to mean that the exploit was release the day of release. Verses 1-day or later cracks.

Different from my understanding. You're thinking of 0-day warez. Here, WP explains it pretty well [wikimedia.org] :

A zero-day (or zero-hour or day zero) attack or threat is a computer threat that tries to exploit computer application vulnerabilities that are unknown to others or the software developer. Zero-day exploits (actual software that uses a security hole to carry out an attack) are used or shared by attackers before the developer of the target software knows about the vulnerability.

The term derives from the age of the exploit. A "zero day" attack occurs on or before the first or "zeroth" day of developer awareness, meaning the developer has not had any opportunity to distribute a security fix to users of the software.

In short, knowledge of the vulnerability exists with attackers before developers. Developers developers developers developers.

Could someone edit that, actually? s/distribute a security fix/address the vulnerability/ If the developer is unaware, they're neither analyzing, patching, notifying users, nor advising workarounds, let alone distributing security fixes.

Re:A confusing summary on /., let me try to do bet (2)

PoopMonkey (932637) | more than 2 years ago | (#38088266)

I've never known 0-day to mean that. 0-day has to me always meant an exploit in the wild before the author is aware of it vs. an exploit taking advantage of a bug that was fixed a month ago but people haven't applied the patch.

Re:A confusing summary on /., let me try to do bet (1)

Kjella (173770) | more than 2 years ago | (#38086702)

To be honest I completely hate ASSERT-style checks, particularly in multi-user systems. One single logic mistake and boom goes the whole server. With exceptions you can at least have a gradual panic. But when you so often resort to pointer-magic and any unterminated string is a recipe for chaos, well... Though it would be nice if exceptions actually worked, which they don't in C++. Try/catching into some third party code and it'll still segfault on you, completely ignoring your attempt to catch any and all exceptions. Sigh.

Re:A confusing summary on /., let me try to do bet (1)

sjames (1099) | more than 2 years ago | (#38087958)

More to the point, since we have an advisory about it and there's a patch, it can no longer be considered zero day. A true zero day vulnerability is one that only the blackhats know about. Expanding that to include a vulnerability that the vendor doesn't yet understand well enough to patch makes sense. But anyone using the term for a bug that has a patch out to fix it is just being over-dramatic.

isc.org Slashdotted. Good job! (1)

L4t3r4lu5 (1216702) | more than 2 years ago | (#38085582)

Hurrr, well done guys. Now nobody can download the patches.

Someone want to set up some mirrors?

Re:isc.org Slashdotted. Good job! (1)

Anonymous Coward | more than 2 years ago | (#38085858)

Just updated my Debian boxes with apt a few minutes ago... I suppose you could always grab the source from a distro and compile.

Re:isc.org Slashdotted. Good job! (1)

Sipper (462582) | more than 2 years ago | (#38086202)

Hurrr, well done guys. Now nobody can download the patches.

Right now the ISC website is still responding.

At least some distributions have already incorporated the patches; for instance, for Debian upgrading simply involves doing an 'apt-get update', 'apt-get upgrade'.
If updated packages are available, it's generally better to get the packages for Bind9 from the distribution rather than recompiling.

However the "fix" in this case may not entirely fix the problem; the current repair withholds the DNS response and will keep Bind9 from crashing and shutting down, but they're not yet sure that there isn't another possible exploit involved. This means there will likely be a follow-on fix once they understand the actual exploit.

Re:isc.org Slashdotted. Good job! (2)

L4t3r4lu5 (1216702) | more than 2 years ago | (#38086676)

So this is a patch to deliberately break the carefully constructed "graceful death" preventing a potential exploit?

Sounds like a GRAND idea...

Re:isc.org Slashdotted. Good job! (0)

Anonymous Coward | more than 2 years ago | (#38087556)

This is a patch to do the required cleanup to remove the offending data from the cache AND bypass the exception that caused the DoS.

APK's monolithic hosts file (5, Funny)

Culture20 (968837) | more than 2 years ago | (#38085666)

APK's monolithic hosts file is looking pretty good at the moment.

Re:APK's monolithic hosts file (1)

itchythebear (2198688) | more than 2 years ago | (#38086056)

lol, +1 funny.

I'm actually kind of surprised he hasn't stopped by to grace us with his randomly spaced and bolded wealth of knowledge...

Re:APK's monolithic hosts file (1)

gl4ss (559668) | more than 2 years ago | (#38086752)

I actually went and downloaded a 16k line hosts file and started using that after seeing that post, you know just for trying it out.
some sites load up faster. I just googled for some file that had been updated last month.

Re:APK's monolithic hosts file (1)

mcavic (2007672) | more than 2 years ago | (#38087206)

monolithic hosts file is looking pretty good at the moment

Yeah, and when my car runs out of gas I'll just push it wherever I want to go.

use NSD (0)

frn123 (242374) | more than 2 years ago | (#38085768)

use NSD. Sleep well.

www.nlnetlabs.nl/projects/nsd/

Unbound, not NSD (2)

bigogre (315585) | more than 2 years ago | (#38086066)

Unbound, also from NL Netlabs, is a recursive resolver. NSD is an authoritative server.

The problem is with Bind as a recursive resolver, not as an authoritative server.

ZOMFG the internets are all crashed? (1)

Rogerborg (306625) | more than 2 years ago | (#38085802)

Like "truly epic coronal mass ejections", lets save the hyperbole for when we can't use it. We'll know that there's a big problem when we can't read about it on Slashdot.

http://ar-blog-baby.blogspot.com (-1)

Anonymous Coward | more than 2 years ago | (#38085804)

Nice

Tip of the iceberg (4, Insightful)

mseeger (40923) | more than 2 years ago | (#38085950)

The "assertion"-problem is only tip of the iceberg.

If an assertion fails, this usually means that someone managed to make the code behave in an unintended way. Since the affect occurred simultaneously at several providers all over the world, this indicates a coordinated attack. The chances are real, someone managed to exploit a buffer overflow (or similar) in BIND.

So we have to look seriously into the possibility that people have a way to execute code with the same permissions as BIND has.

When i got the information this morning, this was an alert topic.

Yours, Martin

Re:Tip of the iceberg (5, Informative)

kqs (1038910) | more than 2 years ago | (#38086176)

The "assertion"-problem is only tip of the iceberg.

If an assertion fails, this usually means that someone managed to make the code behave in an unintended way.

Except that the assertion isn't the problem. The problem is that BIND allows bad data into its cache. The assertion detects this and crashes BIND before the bad data becomes an exploit.

Now, there still may be a way to execute code using this method, but the assertion has alerted everyone to this problem so I expect this particular problem to be solved quickly. And thanks to the assertion-crashes, people will be forced to upgrade rather than running a vulnerable version for the next 5 years.

I'd prefer software without bugs, but since that's impossible, I'll happily take BIND.

Open resolvers (2)

bjb_admin (1204494) | more than 2 years ago | (#38086034)

I am glad I took my lumps and disabled public recursive resolving many years ago on my BIND installations. Only do that for local IP ranges! This eliminates all the resolver issues. Also I found that when the DNS server was open I was getting a constant stream of unusual TXT lookups which were for oddball domains. These contained many K of data. I suspect these requests were fake source IP requests being used as some sort of bandwidth DOS attack.

Re:Open resolvers (4, Insightful)

Short Circuit (52384) | more than 2 years ago | (#38086536)

More likely, the unusual TXT lookups were someone streaming IP over DNS.

Re:Open resolvers (1)

mcavic (2007672) | more than 2 years ago | (#38087154)

someone streaming IP over DNS

If I owned a gun...

Re:Open resolvers (0)

Anonymous Coward | more than 2 years ago | (#38087716)

It's bog slow and requires you to be running a dns server on a machine you have root on, but yes you can:

http://dnstunnel.de/ [dnstunnel.de]

I don't get it... (1)

mcavic (2007672) | more than 2 years ago | (#38087112)

How hard is it to write a DNS server without any vulnerabilities? I know it's complex, but still, come on. It's only the backbone of the Internet we're talking about.

Security tip of the day: Do not use BIND (1, Informative)

gweihir (88907) | more than 2 years ago | (#38088268)

It has an atrocious security history. Seems the rewrite did not accomplish much. Or if you have to use it, lock it into a VM, preferably qemu, so that you get at least some level of isolation.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...