Slashback: Bindery, Locality, Gruviness

Much has happened in the world, some of it even worth reading about. For instance ... More on BIND and where it's headed regarding openness, licensing and other things; an update on Protozilla, and what is undoubtably not the final word on Linuxgruven, SAIR and company.

Why is there a lizard in my hard drive? chromatic writes: "The Protozilla team has responded to the earlier Slashdot article with answers to some common questions." This helps explain a lot of the questions raised in comments about why anyone would want or need to run CGI processes locally.Yet another win for documentation!

The ties that BIND make great cable-holders, too. fredpasteck writes: "LinuxSecurity.com has a FAQ from Paul Vixie that helps to explain some of the controversy and misunderstanding surrounding the ISCs creation of a 'members-only' mailing list. Perhaps the community was a bit quick in their assessment of what's going to happen?"

Do you feel reading Bugtrak makes it easier to talk to people? Speaking of BIND, to dispel any misconceptions which may have entered the minds of readers of this story (which cited the reaction of several Big Names to recent moves to restrict certain information about BIND), Kurt Seifried of Securityportal wrote to clarify:

I actually interviewed Vince/Theo/Dragos/Greg via phone/email seperately, they didn't post those things to Bugtraq. Although they are all Bugtraq users ... hehehehe. (that makes it sound like we're all shooting up heroin or something).

Let it not be said that Bugtraq is a controlled substance.

Stop kicking, stop kicking! A nameless shirker writes: "More 'clarifications' from Linuxgruven CEO Matthew Porter can be found during a recent discussion on the Kansas Linux and Unix Users Association(KULUA) mailing list. His answers were very evasive to what were considered very straightforward (if direct) questions. The beginning of his involvement in the discussion can be found here with follow-ups linked from that message. Other discussion on this topic before and after Porter's response can be found near near the bottom of the following archive thread page.

Just wanted to make sure everyone could see how "clear" Porter makes things in his "responses" to the questions he is asked."

Comments

LinuxGruven.

[smack_attack]

So, does this mean we are going to see some more posts by sequential user ids? It was really quite amusing to see them do damage control (which seemed to cause more problems)

Re:This secret mailing list is a good thing

[prizog]

Now, if a bug is found in BIND, do you really want every script kitty trying to make a name for himself to HACK ROOT on the ROOT NAMESERVERS for the ENTIRE INTERNET? Does this sound like a good plan to you? Wouldn't you rather, since the entire internet depends on them, that they get a chance to be patched up first?

Has it happened yet? No. So, what's wrong with the current model?

BIND perspective

[The Pim]

Though it may be a surprise to many, the security community generally agrees that immediate full disclosure of a discovered vulnerability is normally not the best policy. I cite for one rain forest puppy's Full Disclosure Policy, which has been widely approved and followed (see BugTrag archives for evidence). RFPolicy recommends a five day minimum before disclosure, even if the software maintainers are unresponsive, a ten day minimum if they at least respond, and arbitrary deferment of disclosure if they cooperate.

What is the purpose of the delay? To minimize the damage done by the vulnerability. Immediate disclosure means everyone's vulnerable until the news spreads, and even then, the only option is to disable the vulnerable program until a satisfactory fix is found (which is costly enough that many people will not disable it). Waiting until a fix is found still leaves people vulnerable while the news spreads, and subsequently while they evaluate the fix (a non-trivial task for critical systems), but it usually results in less overall harm. A logical next step is to inform, in confidence, the users most at risk prior to public disclosure. That, if we give them the benefit of the doubt, is all the ISC intends to do.

There are two problems with this strategy: It offends some people because it is inegalitarian and secretive; and the chance of a leak or independent discovery go up as the number of people in the know increases and time passes. If you hold an extreme version of the first position, you should argue that not even the program maintainers should get advance notice. This is a legitimate stance, but is by no means consensus among security researchers. Otherwise, you must admit that it's a trade-off, not a black-and-white issue.

Consider: Imagine you found a hole in a program you were using. Obviously, you would fix it locally before announcing it. Would you also get a review of your analysis from a trusted expert before disclosing? What if your friend were using it--would you tell him first? What if an organization you admire were at risk? It's a delicate balance.

I'm not defending Vixie's specific policy, I just want to point out it is not prima facie unreasonable.

Re:Sick of BIND? Me too.

[The Famous Brett Wat]

Due to the number of highly-moderated recommendations I've seen of this software on Slashdot, I decided to look into it. First up, I noted it's not in Debian, so I went hunting at cr.yp.to to see what the issue might be that keeps it out. My conclusion is that I'd be most happy to try it in principle, but there are two problems with it.

1. It's free beer. I don't mind free beer software: I use quite a bit of it. I prefer stuff that can actually be modified as needed, however, and not by distributing patches. If this were the only problem, Debian might be able to distribute it as non-free sotware, but then there's the second problem...
2. You can't modify it, and it has its own ideas about where to install stuff in the name of compatibility. Now I'm all for compatibility, but I think this kind of fiat is a really wrong way to try to go about it. I don't want to install this program on the grounds that it's going to mess up my nicely-structured Debian system. Debian's layout is as arbitrary as any other, really, but they've made it nice and consistent. The kind of solipsism demonstrated here by Bernstein is not welcome on my computer.

Maybe BIND sucks, but it's still got my vote for now. I'd buy Mr Vixie lunch if he was ever in the area.

An open question to Paul Vixie and the Bind People

[Greyfox]

Do you feel your product is so insecure that it needs a closed, members only discussion list?

Sick of BIND? Me too.

[defile]

If you're a competent sys admin wishing you had an alternative to Vixie Inside, there's some hope.

Have a gander at djbdns. This is software done right people.

Instead of upgrading to the latest version of bind because of yet another security hole, I decided to switch. And I've been happy ever since.

I've been searching for an alternative forever and I still can't believe I hadn't come across djbdns until someone on Slashdot posted it. There must be others like me.

Re:Secret Mailing lists are still evil.

[mihalis]

ISC is trying to make money, yes, but it is a non-profit organization. They need the money to keep the global DNS system working. I assume you want that.

The most important port of an Open Source organization is that the Source is Open, which it is in this case. They are allowed to have private discussions just like anyone else, but anything substantive that is done to the code as a result of these discussions will be available just as soon as they've fixed certain critical nameservers.

If it weren't for this slashback this would be another slashdot hall of shame entry.

Someone would pay to be on this mailing list because anyone who runs a critical nameserver, or has customers that do so with their software will find it essential, no question. THAT is all.

Chris Morgan

They didn't listen to any criticism

[Lish]

Having read the FAQ, I don't think that the community "was a bit quick in their assessment of what's going to happen" at all. BIND is moving to a security-through-obscurity model. That much is clear. Mr. Vixie's answers in the FAQ indicate that the ISC did not take any of the criticism/comments from the community about this move seriously. Some of the answers sound like a parent brushing off questions from a small child. "Now, run along, and trust us to fix stuff in time. You don't need to know when a bug exists."

For example: the answer that referred to (paraphrased) "if anyone else's software runs on 80% of servers and is as dominant as ours, then we'll take a lesson from them" smacks horribly of arrogance. Nah, couldn't be that anything but the most widespread software would be the best, could it? *cough*Microsoft*cough*Sendmail*ehem* Just because your software is on more machines than others, doesn't mean it isn't "full of holes."

Basically, the ISC is closing off the information loop for its own benefit and leaving the little guys in the dust. I could understand this better if it were a purely commercial entity, but their purpose is to serve the community, not just an elite, specially chosen group who is willing (and able) to fork over the money to be in on the secrets. This is not right and that is exactly why the community is in an uproar.

Anybody who's thinking of migrating to BIND9: if you're going to retool for the new version anyway, just switch to something else. Save the headache in the long run.

This secret mailing list is a good thing

[Ben Schumin]

I'm tired of hearing about this secret mailing list thing, but I will explain to all of you why it is a good thing. BIND runs the dns for the entire internet. The root nameservers run bind. These are the nameservers that all the other nameservers use to figure out where they need to go. Your ISP most likely runs bind. Everyone runs bind.

Now, if a bug is found in BIND, do you really want every script kitty trying to make a name for himself to HACK ROOT on the ROOT NAMESERVERS for the ENTIRE INTERNET? Does this sound like a good plan to you? Wouldn't you rather, since the entire internet depends on them, that they get a chance to be patched up first?

I realize we're all in favor of open processes, but I think if anything this proves that in some situations they aren't appropriate.

As an example, have you ever left your front door unlocked? Would you prefer if someone told you personally, so you could fix it? Or would you rather they sent this information to the doorunlockedtraq mailing list to let you and everyone else know of the mistake you made, before you get a chance to fix it?

Re:This secret mailing list is a good thing

[biglig2]

Let us work the analogy further...

It is dicovered that certain models of the Acme "Gluon" door lock can be opened with wet spagetti.

This lock is used on lots of people's doors, and also on the door to the local army camps' armory, the local jail, and the town bank.

The lock makers, being responsible etc., want to tell people to change their locks, so they put an ad in the paper.

Now, the question here is, is it reasonable for them to quickly ring the camp, jail and bank, to tell them to change their locks straight away, and only then put the ad in the paper?

If yes, then the average joe has an insecure lock for a few dsays longer than strictly necessary, and has a risk of getting burgled if someone else discovers the spagetti trick.

If no, then there is a risk that the prisoners will escape, steal the guns, and rob the bank.

Re:This secret mailing list is a good thing

[Anoriymous Coward]

Or put another way, since the entire internet runs BIND, including myself on my poxy little home network, should the self-chosen elite (or worse, a pecuniously chosen elite) be allowed to know when your DNS server is vulnerable before you do?

To rework your door analogy, suppose a particular model of lock had a problem. Perhaps it can be opened with a piece of uncooked spaghetti. Would you rather that everyone was told, or just those people "with a reason to know", such as locksmiths, process servers and baillifs? Plus of course, any incognito burglars who'd stumped up the change to get on the list. Remember that you still think your door is locked.

BIND to djddns Migration Guide/ HOWTO

[DrProton]

Stop giving the knee jerk "switch to djbdns" replies.

It's a free country.

Installing djbdns is a pain in the ass.

tar zxf djbdns-1.04.tar.gz
cd djbdns-1.04
make
make setup check.

what a pain in the ass!

Switching from BIND to djbdns? Here's a howto: BIND-to-djbdns Migration Guide / HOWTO

Re:BIND to djddns Migration Guide/ HOWTO

[timftbf]

Hmm... followed the links from that HOWTO, and they're trying to convince me that the tinydns zone file format is more human-readable and easier to maintain than BIND zone files.

Now, more easily *machine* readable / writable I'll buy - autogenerating BIND zone files needs a little care, and parsing them is non-trivial. But to a human, which is easier to follow:

host.dom.ain IN A 1.2.3.4

which quite clearly tells you which type of record you're dealing with, or:

+host.dom.ain:1.2.3.4:0:4000000038af1379

which unless you're editing the damn things day-in, day-out, you're not going to remember which meaningless symbols correspond to which types of resource record.

The djbdns docs seem to advocate maintaining the DNS via the 'add-foo' scripts rather than editing zone files, secondarying is one of a variety of hacks ('run the axfr prog, filter the output in various ways, rebuild the database' or 'not our problem, use rsync'), and starting and stopping the daemons is non-standard.

The whole design simply doesn't work for me.

Regards,
Tim.

Re:Uhh, you didn't read the FAQ at all.

[f5426]

I laughed my ass off the so-called FAQ. Generally FAQs are done with real questions. Here, the answer ISC want to giuve to the community are re-written as questions. Like: "You mean this whole thing is just to _add_ a new level of access for the organizations ISC considers critical to the Internet's infrastructure."

> The FAQ makes it absolutely, positively clear that EVERY SINGLE CURRENT AVENUE of bug notification will REMAIN IN PLACE.

Use you head.

First, current way of handling bugs isn't correct, or this member-only list would not be necessary.

Second, with a different channel for the most demanding users, do you beleive that the current avenues will become more or less performant ?

Third, by having a fee-based list for most important security issue, do you think that ISC won't have an interest conflict ?

Fourth, this FAQ is written from the sole point of view of ISC. You need to take its content with a grain of salt, particulary due to the biased questions.

Fifth, what I found most missing are the guarantees. For instance, if there was something like a way to get access to all the list archive automatically after, say 7 days, I would be much less suspicious.

Cheers,

--fred

Re:An open question to Paul Vixie and the Bind Peo

[Bob Uhl]

It's not that it is so insecure, it is that it is so vital. One may model the risk of publicising information by looking at the percentage of folks using the software--if .01 of the population uses it, a publicised risk won't hurt many. If .99 use it, a publicised risk could hurt nearly everyone. When you realise that BIND runs the root servers and the TLDs, you must accept that a flaw in it could take out those machines, and thus the entire domain name system; the 'net would be fragmented into little pockets of local namespaces.

The odds of a bug are not important to the equation: if in all of history there were one dangerous bug in BIND, it would still be important that it be fixed and the information be distributed to those important servers first.

To those who argue that security through obscurity is a bad idea: yes, it is. But it is also better than no security. To pubicise problems before a fix has been made is equivalent to taking an ad out in the paper stating that one's locks no longer function. Far safer to keep that information private and try to fix those locks ASAP, hoping that for a moment the insecurity will escape notice.

It's not as though DNS is a non-vital service which can be turned off in case of security flaws; rather, it must continue to run, even when it is known that it has problems. One can stop running irc if it has problems; DNS, OTOH, is essential.

Well, not really, but who remembers IP addresses anymore?

Secret Mailing lists are still evil.

[Kiss the Blade]

I just read the FAQ, and I find myself ill-convinced by the reasons given. It just strikes me as being bad in a couple of ways:

1)It is a clear attempt to make money by the ISC. They are supposed to develop Open Source software for the Interent. Money corrupts that.

2)More importantly, it is the secret nature of the list which is bad. The most important part of an Open Source organisation is that information is free. Here they are trying to make it secret.

Now, if you don't believe me, ask yourself this. Why would someone pay to be on this mailing list? What would they get out of it, that they couldn't get normally? I would guess that they get influence and information that gives them an unfair advantage. Secret Mailing lists for OSS related organisations are antithetical to the spirit of the OSS community, from which they benefit. That is all.

KTB:Lover, Poet, Artiste, Aesthete, Programmer.

Re:Secret Mailing lists are still evil.

[nightfire-unique]

More importantly, it is the secret nature of the list which is bad. The most important part of an Open Source organisation is that information is free. Here they are trying to make it secret.

Agreed; this is a problem, but for another reason as well: this eliminates a certain amount of liability for making mistakes.

Closed source software vendors are often more careless in the development of their products than open source vendors, knowing that there is less a chance that a vulnerability will become publicized (benefit of obscured code). The more public attention (via open mailing lists, open code, etc) there is, the more careful the programmers and QA teams must be, to avoid damaging their reputation (benefit of shared code/information).

I suspect this class division (trusted groups vs. the rest of the world) lessens the potential damage a serious security flaw could cause, which may in turn lower release quality.

--
All men are great
before declaring war

Wow!

[Enahs]

Upon further inspection, I realize that Protozilla is probably the best thing since sliced bread. It sure would have come in handy this afternoon when I was working on Linuxdrivel.

Security through obscurity

[YuppieScum]

Hm...

I'd always thought "security through obscurity" was a bad thing...