Keep a lid on it
Posted : Tuesday July 22nd, 2008

So if you don't know there was been a fairly large story about a security hole in DNS. In short a problem in the way that most cacheing DNS servers are implemented means that they can be "poisoned". In plain English this means that many (most) DNS servers could be used by malicious persons to return faulty information for name resolution requests. For example a request for www.somebank.com would direct a user to a phishing site in Latvia.

Now what's more interesting to me then the flaw is the process in which the the flaw has been handled. After someone discovered the flaw they then decided to not disclose the details about the flaw to the general public. Instead they decided to work with major DNS makers to get patches for the flaw built and available for deployment, notify people that they should patch and then reveal the details of the flaw at a conference on security.

Since then there has been speculation about the flaw and in what should not be a great surprise the details were leaked yesterday and some degree of panic, along with a great deal of accusations being thrown about have ensued.

So the topic here that I think is worth discussing is whether the original idea, hold bank detail disclosure to all but trusted vendors was a good or bad idea. And I think it's an interesting topic because there are a number of viewpoints as well a number of issues specific to this case that are important to consider.

Security by Obscurity is a Mistake

This was the major argument raised by a number of people, mainly from the open-source community. In essence the point raised is that by not disclosing details the problem became one where systems were only secure because the details were not known and not because the systems were/are actually secure.

In general I agree with this assessment. There are too many people who still think that security by obscurity works, that a hole isn't bad as long as it isn't discussed publicly. Beyond the fact that this seems to me a logical fallacy the evidence would seem to show that muddled thinking like this has proven to be false as well.

Not releasing the details publicly gives time for vendors to react

A counter argument to above is that by announcing a flaw but holding back details it gives vendors at least some time to develop patches for the exploit so that the announcement doesn't trigger a flood of compromised servers. Under this theory holding back details helps everyone. I think there is something to the general underpinnings here at least in some cases.

It's the discoverers intellectual property and they can do what they want with it

This is a general distillation of a few of the statements I saw defending the non-release. The theory being here that the discoverer of a bug gets to dictate the how and when of details of a bug by way of priority.

I find this position difficult to defend. If it is your software, well sure, do as you like. But playing a game of priority claiming and deciding that this gives you the "right" to determine when and how details will be released when the software is written by others? I don't find that I can condone that kind of behaviour.

In my opinion

I think that in reviewing this case I find myself more in favour then ever before about open-source concepts and the idea that making information public is a good thing.

Now contrary to this, in this specific case I think there is something to be said for trying to give vendors (and administrators) some lead time to patch systems. Namely because DNS is such a fundamental part of Internet services and major compromises to the DNS system could do major long-term damage to the general public perception of the safety and reliability of these systems.

However. I believe the discoverer in the end was less concerned with giving people time to patch then they were obsessed with being hailed as the discoverer of this flaw. The fact of the matter is that knowledge of the flaws which form the basis of the exploit are already in the public domain. Simply by reading some of the notifications from various security agencies combined with the results and explanations of various tests made available on websites I believe provided more than enough information for a person who was looking for an exploit to determine in a general case what the flaws are/were and how to exploit them.

And then there is the matter of the discoverer deciding to officially reveal all at a security conference which is nothing short of grandstanding.

Did the discoverer do a favour to everyone? Yes. But there was a better way of dealing with it. Contacting vendors and keeping quiet about the flaw for a couple of weeks and then announcing everything was the right way to go with this. It's the way it's happened before and it keeps the right balance between real concerns about mass compromises, a right to claim to precedence and the real need to make information public. Trying to treat a discovery like this as a viral marketing campaign for the discoverer was a bad route to go and the developing fiasco is only proof of this.

Hopefully in future security experts who discover flaws will handle them in a way that is more professional and more in the public interest then simply being obsessed with the opportunities for publicity.

Tags

disclose  discussion  DNS  hide  open  security  source 

Categories

Security  Internet 

Comments