Slashdot Mirror
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?"
Why don't companies just release a patch without telling exactly what the problem is? We see game companies do it all the time. "We have fixed an undisclosed vulnerability..." Why don't we apply that where it is more critical?
Not only "land of the free" but "land of the lawyers" who love a good old 1st amendment smackdown. Shihar 153932
Someone tells you that you have a security hole; you fix it - A.S.A.P!!
Evil people don't think they're evil. - George Lucas, Making of Ep III
This is a very tough one because it is multi-faceted. The most common argument against researchers publishing is it practically guarantees an exploit will surface in the wild sooner rather than later, possibly before a patch is available. OTOH, if they don't publish, it might be discovered by criminals first and exploited more quietly, gaining a foothold in the wild before anyone even knows the hole is there. Sort of a damned if you do, damned if you don't scenario.
But when a vendor is sitting on the report and not issuing a patch, it can grow increasingly frustrating for the researcher. They not only have to watch people trundle along, blithely unaware of this gaping hole in their systems, but they cannot get their proper credit for the discovery. It's a bit like publishing for academics. Getting to take credit for the discovery of a security vulnerability has certain perks that the researchers are denied as they sit quietly and wait for some corporation to decide when to go public with the announcement of the hole and the patch for it.
Probably the best solution would be to have a set of universal guidelines set at one of the major conferences. Something that takes fairness to the researcher, fairness to the software vendor, and fairness to the public into account. I know, I sound like a politician saying "let's form a committee to study this", but I doubt that any one person has a solution that makes everyone happy or could even be considered a fair compromise by all involved parties.
- Greg
Start a happiness pandemic
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Yet, prevention does not mean improved security. How do we actually improve security?
The answer is massive class-action lawsuit. Consider the following scenario. A manager at Microsoft badgers his employees in order to hustle an Internet software program out the door. The product is now flawed and open to attack by worms and viruses.
Some graduate student at CMU identifies the flaw and then immediately announces the problem on her web site. Some savy users uninstall the flawed product. Most users are unaware of the situation. Meanwhile virus writers have a field day and immediately unleash worms that wreck havoc on the affected computers.
Now, here's where the improved security occurs. The customers who bought the flawed product initiate a class-action lawsuit against Microsoft and win $10 billion from the company. Microsoft then fires the manager who forced his employees to hustle a product to completion. The manager of that manager is also fired.
Rest assured. Microsoft will no longer sell a hustled-to-completion product. Its software programs will be bullet proof.
I can't believe that this question:
"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?"
is even being seriously asked. Of COURSE the onus is on the software compnay...they made the damn thing and are making the money from it, right?
This could only be a question in the software world. Before making the jump to IT, I built acoustic guitars for years. If I BUILT it wrong, not only did I hear about it, and not only did a lot of my potential clients hear about it, but I HAD to fix it, and not next week, but ASAP.
I'm honestly curious as to how the rules got changed for software.
Boycott everything - they're all trying to fuck you one way or another
This makes an interesting read
http://wiretrip.net/rfp/policy.html
Well thought document, written with input from big names in the computer security scene.
(Posting anonymously for career protection.)
... they apparently didn't get it, and they actually wanted to distribute the full working exploit very widely inside the company.... I was told ... "Give this to all the sales engineers and to all the pen testers."
The problem has been posited as researchers v. software companies. The problem is, there are some researchers who work for software companies, some very dirty software companies, and their management would very much like to take market share from their competitors.
Someone else gets hurt? That's Cisco's problem.
-----------
WN: So ISS knew the seriousness of the bug.
Lynn: Yes, they did. In fact, at one point
WN: Why would they want you to do that?
Lynn: Well, because it bruises Cisco, remember? Mind you, this was something that Cisco hadn't gone public with yet and that's not useful to pen testers because what do they advise their customers to do (to protect themselves if no information about the vulnerability has been released yet)?
I told them, "You do realize if you do that, it's going to leak?" And (one of the ISS guys) says, "That's Cisco's problem." And then (another ISS guy) turns to me and says that they need to understand this could be their Witty worm. I was like, Whoa, what meeting did I walk into?
(The Witty worm was a particularly aggressive and destructive code released by someone last year that targeted computer systems running a security program made by Internet Security Systems and even more specifically targeted military bases using the software. It infected more than 12,000 servers and computer systems in about an hour. Because of the worm's speed in spreading and its creators' apparent knowledge of who ISS' customers were, some security experts speculated that someone working for or connected to ISS might have been responsible for writing and releasing it.)
At that point, I told them all no, and they fought it and I resigned right there on the spot. And this was about a month ago.
I thought they were handling this in a non-ethical manner. Because it was just way too fast and loose with who can see this.... I mean, I don't even want people to see it now. (ISS talked him out of the resignation by agreeing to give him control over who could see or have the exploit.)
---------
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.
Overall, disclosure of a problem is always in the USERS best interest
I disagree to an extent. There are a couple reasons.
First, spreading a virus or other malicious code would probably be easier than patching the problem, at least most of the time. This means that exploits for a vulnerability would be be out before fixes for them.
I'd prefer the uncertainty that hackers may or may not have found a vulnerability above the certainty that they can find it, even at the cost of being unaware of the vulnerability itself.
Second, what am I supposed to do if I do know about the vulnerability? Change software? Even for a home user this is a substantial undertaking, and sometimes impossible. (For instance, even though I like Linux and dual-boot with Gentoo, I do most of by stuff in Windows because there are a couple things I *can't* in Linux.) In a corporate world, the situation is even worse.
Again, in many cases, we're back to the same problem: I have to run software with a vulnerability (i.e. even if I know about it I can't do anything), do I want that vulnerability known by a lot of people or as few as possible?
Finally, what am I supposed to do even if I COULD change any software at will? Follow all the websites where security stuff would be posted to see if something was broken? Yeah right, many people don't even install patches. I don't have time to pay attention to security sites. Even if I did, I might not have the knowledge to evaluate how bad of a threat something was.
Now, I do think there comes a point where if the company is sitting on its hands and doing nothing that something has to be done and the vulnerability should be released to the world in an attempt to force it to take action, but as long as the company is making a good attempt I think that it should remain as secret as practical. (I also think that vulnerabilities should be released a couple weeks, maybe a month, after the patches are, both to give the public information about the general security of that company's products and so that developers can learn from the mistakes of others.)
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.
At the very least, I believe in full disclosure to the company that writes the software- but public disclosure opens up too many risks- yes, someone else may find it, but I really don't think that Microsoft purposely leaves out fixes- they have lots of fixes to put in, and they have to prioritize them. Yes, if it is public, it gets higher priority, but they have finite resources to investigate the fix, find it, fix it, and then test to make sure that they don't break anything else.
I think that what the open source community fails to realize is the huge amount of effort that goes into testing. I used to work for one of the big computer manufacturers- (rhymes with Hell), and the software that is released on a system (my experience is with servers) is usually frozen months in advance so that the different phases of test can pound on it, not just so that they can find errors, but so that they can characterize those errors. The fix for a critical error may be done in a day, but the testing may take weeks- to test with different hardware, system software, amount of RAM, HD, different processors... the list is long- but ultimately what they are trying to make sure is that a fix for one thing doesn't cause something else to break in a worse way. This is particularly important when you are maintaining code someone else wrote- you may not fully realize why it was done that way... until it is too late.
Unfortunately, the IP issues often force companies not to reveal what they are doing. Every single person I worked with was extremely conscientious about their work, they take flaws very seriously, but remember, their priorities are not the same as yours, and if you could see the scope of what they are working on, you might be able to better understand why their priorities are where they are. On the other hand, they don't know you from Adam, and you might just be one of those black hats- so they can't reveal the HUGE GAPING HOLE they just found, to show you that they really do care about the tiny (but significant) hole you found.
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 ?
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?
Its software programs will be bullet proof.
Another thing to think about:
100.000% reliable software costs exponentially more than 100.00% reliable software, which costs exponentially more than 100.0% reliable software. Companies cannot make a profit if they have to eat those costs, so they will have to be passed on to the purchaser.
Given the choice between two vendors' products, that effectively do the same thing:
1. Costs $1,000, took an extra 5 years to finish (and is thus 5 years behind the times), but is guaranteed to be "bug-free" (if there can ever be such a thing); versus
2. Costs $50, integrates the latest technologies, but is riddled with bugs that will impact all of its users at some point, including some security vulnerabilities that will impact some percentage of its users and requires its users to install patches once a month.
Which do you think is going to be more successful?
I hope the difference is clear enough.
I'm sure the proprietary houses would love to see the laws written to make this happen but the fact remains that a proper and practical implementation of software liability is possible.
As with everything else, I feel the defining line should be drawn at the point of transfer.
Allow me to quote the venerable Donald Rumsfeld:
Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know.