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.

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 ?