What is Responsible Disclosure for Security Flaws?

Silverdot writes "In an article on ZDNet, the author brought up a few cases of uneasy relationships between security researchers and software firms. While those who report the bugs should first seek to notify and work with the software firm to resolve the flaw, One researcher commented: "All researchers should follow responsible disclosure guidelines, but if a vendor like Microsoft takes six months to a year to fix a flaw, a researcher has every right to release the details." Should the onus be on the software firm to manage each issue and the relationship well, or does it fall to the morally responsible user?"

Comments

The question should be...

[Karma_fucker_sucker]

What's the reasonable response time to fix the problem?

Someone tells you that you have a security hole; you fix it - A.S.A.P!!

Tact

[jellomizer]

The trick to proper security flaw reporting is understanding what is the tactful way to state it vs. tactless way.

An example of a tactful way first report it to the software developers and see if there is a patch. If not then get a little more forceful and release to the public that there is a flaw in a feature on this product and it seems to effect this range of people.

An example of a tactless method is to make a root kit that takes advantage of that flaw. Or tell the general public how to reproduce it.

You will need to remember what you say publicly will be used by people who will do good things about it and bad things about with it. So if you give them enough information to say block a port or temporarily turn off a feature vs. giving giving the bad guy a way in while the person will need to figure out what you did in your root kit then find that is the problem.

Be mindful when you report the flaw to the software company as well. You are telling them that they have an ugly baby and most people don't want to hear that. Try to be friendly with them but stern on the severity on the flaw. When it comes to reporting flaws you are no longer dealing with computers but with people and if you piss them off to much they will be less then helpful.

Re:Tact

[TheRealMindChild]

Sometimes, it isn't so easy. Lord knows I have found and reported my share of exploits. Of them, a few took a bit too long, but communicated with me a majority of the way. One of them, however, told me they knew about it, decided it was better to call me an asshole, and to pay them consulting fees if I wanted X security hole resolved.

In the latter case, the only course of action (not due to spite mind you, though it felt good) was to release a usable exploit. The creator of said software had no intentions of ever fixing it. They had every intention of belittling anyone who brought such things to their attention. For me, the only way I would see this work, is if all of a sudden, the world was afraid to use software Y because a simple script kiddie could comprimise them.

blame shifting

[cahiha]

The two groups who are responsible for security problems are software vendors and companies that buy buggy software and use them for critical data. Those are the primary parties at fault when security problems cause loss of money or life. Unfortunately, both of those groups are increasingly successful at trying to blame other people and creating legal obligations for other people.

What we really need is a market driven solution. If MegaBank discloses 200000 customer records to criminals due to a security bug in their Loses XP operating system, then they should be responsible for all the identity theft-related expenses that that causes their customers, plus statutory damages (say, $1000/customer) for distress and inconvenience for their customers. If they do that sort of thing too often, they'll go out of business. That kind of financial risk will force them to demand guarantees from the creator of the Loses XP operating system, which will force that company to finally get a handle on security or go out of business themselves and be replaced by companies that understand security. And if it turns out that it simply isn't possible to do something securely with software, well then only the non-computerized companies will survive in the market.

So, what's the "responsible" way of disclosing security bugs? Any way you feel like it, as far as I'm concerned. The security problem in someone else's software is not your responsibility in any way, shape, or form.

Re:The cost of secrecy

[drgonzo59]

I disagree. I think they should disclose it as soon as possible.

First of all they should stop calling the mistakes"bugs". There are not "bugs" there, these are mistakes. If work for Ford and I am responsible for the carburators, I screw up and the QA never catches it and then people's cars are blowing up, it would not be called a "bug" as if something just crawled in there without anybody's fault, it would be _my_ mistake, a personal responsability.

The software companies are churning code to get it out of the door without adequate testing, it is their fault. If someone exploits it, it both software makers fault and the exploiter's. The company should restitute the costs associated with the loss. Hopefully, that would promote a culture of responsability, and software engineering would be taken more serously, just like mechanical, electrical or nuclear engineering is.

Chances are that if there is immediate disclosure, the users will have a chance to stop using the product until a patch is available. Every day until the patch is issued they should just bill the software company. That would be a great incentive to test well, code carefully and fix the problems faster.

Openswan project directly affected

[jehreg]

The Openswan project is directly affected by this this month. We were contacted by an agency and asked to sign a non-disclosure agreement, following which they would tell us of a possible vulnerability in our code. This non-disclosure would prevent us to release details of the vulnerability until such time as the rest of the "group" would be ready for it to be announced.

In the case of an Open Source product, we cannot even do a "stealth" fix; we have to describe what each patch does when we commit it to CVS. That would make the vulnerability public and would be a no-no to this agency.

In essence, the agency could decide which bug we could fix and which ones we could not.

I see this as the equivalent to blackmail: Sign our non-disclosure and we will give you a possible vulnerability; don't sign it and you will look bad when the vulnerability is made public.

I am a CISSP, and quite willing to hold on the patch until others can fix their code if the allowed time is reasonable, but the non-disclosure is broad and has no time limitations... So what the heck should we do ?

Take this to the extremes

[Quicksilver]

Say a new DMCA law is enacted that makes it illegal to disclose security flaws. Consider that companies can now fire all but a few of the people involved in security patches and boost profit. How many security flaws do you think will get fixed? How long after a worm is released since staff has been reduced?

Say that a new law (along the lines of collusion) is enacted that makes it illegal to only disclose to a company and not to the public since you are putting the public at risk by withholding information... thus helping said company. How many security flaws do you think will get fixed?

If I buy a bike lock that can be picked with an ordinary pen do I want to know about it? Will the company that makes it do anything until everyone knows?