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?"
The cost of secrecy is high. Reasonable response times ( up to, say, 3 months) before disclosure should be allowed - even for firms that seem to be sitting on their hands, and if the firm is close to a patch and they are willing to communicate and work with the researcher a longer time may be reasonable. Overall, disclosure of a problem is always in the USERS best interest, and secrecy is always in the SOFTWARE FIRMS best interest. The longer a known security issue exists, in secret, the more likely it is that someone else has found it - and that puts everyone at risk. The rights of users ( who are victims of the software firms bad code) should always come before the rights of the software firm. Always. So this means disclosure should be seen as a blessing. Those who complain about irresponsible researchers putting everyone at risk are wrong - everyone is already AT RISK. Failure to let me know what risks I face should be seen as the problem. I need to know.
I have nothing to hide. So, why are you spying on me?
Sell it to the Russians for $1 meelion dollar
"Responsible disclosure" is a propganda term propogated by the software firms to a) get as much time as possible to fix security holes, and b) indemnify themselves as much as possible against any public disclosure of said security holes by labeling the disclosers as 'irresponsible'.
If a security hole exists, it exists, despite how much public discussion about said hole is quashed. Today more than ever, there are unscrupulous people out there laboring to find and take advantage of these holes. Muzzling the virtuous hackers, who only wish to make things more secure, is counterproductive in the extreme. The only 'responsible disclosure' is full and immediate disclosure.
____
~ |rip/\/\aster /\/\onkey
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
I'd be the first to tell people about my security flaws, hell i'd advertise them. I'm just going to make some half-ass excuse and blame someone else anyway. at least thats what all the k00l keds do dez d4yz.
i don't care
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
If you find a security hole in someone else's code you can either:
1) use the DJB approach: reveal the hole in a public forum, preferably with a working exploit.
2) use my preferred approach: fix your clients' copies of the program, and otherwise keep quiet. Consider it a competitive advantage when the next Apache/SSH/PHP worm hits.
Any other approach is an utter waste of time, for everyone except the vendor.
If you reveal the flaw only to the author, you are:
a) Working for someone else without getting paid.
b) Saying "it's okay" to write software with security holes, because shucks, some kind soul will fix it for you.
c) Not telling the rest of us, the sysadmins of the world, how to protect our own systems. You see, the company or author has already demonstrated incompetence. Why help them? Of course you don't owe anybody anything (see point #a) but if you're going to tell anybody, tell the people with the most to lose!
Of course, I'm assuming we're working with software where you have the source code. Secure software without source code is an oxymoron. And no, I don't think the license makes code more secure, since maybe 95% of the coders out there can't code properly. My ability to audit is what makes it more secure, and yes, I do as much of that as I can.
Let me make the point clear: I don't care if the author fixes the code or not, or how quickly he can "patch". I need to know the details of the problem so I can solve it myself. That's what's important.
People who advocate "irresponsible disclosure" (my term for any disclosure that doesn't inform the end-user first) are really secretly afraid that someone will someday find flaws in THEIR systems and embarrass them. But that's the point: embarrassment is a cost, and people will try to minimize costs any way they can. At some point they will actually try writing secure software. And maybe at some point, users will start demanding secure software.
I think we can all agree that the security situation is getting worse, not better. Most of the software I see these days is garbage, to put it mildly. Bloated, complex, insecure.
Constantly holding the hand of authors via irresponsible disclosure is not going to solve the problem. Do you want to wait until the government regulates software, basically punishing everybody for the sins of the incompetent? Or should we let market forces do their thing?
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
If the software company waits until exploits are wild before they patch something, they will have screwed themselves, and you can point and laugh and get all the publicity for alerting them of the vulnerability years before it was exploited and patched. It takes patience, but being able to say "I told you so" is much better than advertising a vulnerability before it's patched. Software companies like to schedule their security updates to minimize exposure. If the vulnerabilities haven't been exploited yet (who knows?), it makes sense to wait a while and release the patches in one well publicized bundle.
I mostly agree with your overall analysis, but I'm compelled to point out that this one statement seems self-contradicting. What is the difference whether a security issue is "known...in secret" rather than simply "unknown"? I submit that a better way to say this would be that "the longer any security issue exists, the more likely it is that someone else has found it," without regard to how known or unknown it may be during the interim.
The only way this is not true is if you consider the (perhaps non-trivial) cases where the "secret" is leaked, intentionally or otherwise.
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.
Responsible disclosure from Microsoft's perspective: You tell us and only us. We'll tell the rest of the world when we think it's necessary (if ever).
The NSA: The only part of the US government that actually listens.
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.
Common Sense is sometimes violated egregiously by one side or another, and then this is raised as an issue. If a security researcher sends one email to some ill-checked "bugs@" address and gets no response, then just releases a couple weeks later, that's irresponsible.
When someone emails a vendor many times at many addresses, finally gets a response where they tell him, "We're looking into it", and then proceeds to cease communicating for 45 days, that's irresponsible by the vendor, and the researcher has every right (and some would say, a responsibility) to publish.
Where's the middle ground? Well, it's a wide open space. Those without bad ulterior motives (ie, publicity-hungry or vendor-hating researchers, or head-in-sand or deny-first-ask-questions-later vendors) don't really have much difficulty negotiating the middle ground, because there's a lot of room. The problem, of course, is that the only time you *hear* about disclosure issues is when someone is being a muttonhead - either vendors trying to keep secrets, or researchers who feel no sense of responsibility or make the most token efforts to make contact. For the rest, there's little debate, because it's just easy to do it right.
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
Shouldn't it be who is responsible?
:)) could take sometime.
Anyway, more on topic: I don't think its cut and dried situation, I think that disclosing a bug immediately can be good in one situation but harmful in another.
For a company the size of Microsoft, sitting on a bug for 6 months to a year may be the time it takes to adequately test their patches. Remember, for years they strived to make their software work with everything under the sun and make it backwards compatible with everything under the prehistoric sun. Its conceivable that creating a patch that is thoroughly testing (at Microsoft?
They fucked Kismet up the ass royally at Defcon.
With that said, if an exploit is discovered by one person, it's been discovered by many. Regardless of how widely known the exploit is, the customer is still vulnerable, and the software company has an obligation to patch their software.
If software companies started getting sued for the damages that their software was responsible for,then I think we'd see a much different security landscape in IT.
Since when did operating systems become a religion?
I really love the Full public disclusure advocates. They seem to have a romantic view of the black hats. Rather than a selection of small groups, they seem to imagine a vast international consipracy.
The justification seems to be that they might already know of the vulnerability. A weak argument if ever there was one. Just because some black hats know of it doesn't mean all of them do. And there's no evidence that any of them know of the vulnerability before the flaw is revealed.
We change from a possibility that some blackhats know of a flaw to a certainty that all blackhats know of the flaw.
And if there's evidence to counter their claims, the full disclosure advcates will come up with the most ludicrous scenarios.
Recently there was evidence that they did not, after a virus was released that exploited a recently reveled vulnerability. I pointed this out. The explanation was that the blackhats already knew of it but were being cagey. Since it was now public, they had to exploit it as much as possible before it's patched. Of course - occams razor would suggest simply that none of them already knew about it.
There are basically two types of disclosure: 1) Disclosure of the existence vulnerability and 2) Disclosure of an exploit for a vulnerability. They are, of course, related. But type 1 doesn't immediately put users at serious risk. Hackers would still need to pick apart the underlying execution code and then work on developing a functional exploit. This can take several hours to (hopefully) several days or longer. At least in this case, the presumably embarassed and harassed-by-customers vendor gets motivated to quickly issue a patch. Type 2 disclosures should be shunned by everyone. These present an immediate hazard to end users and provide no conceivable benefit to anyone (except PR to the group that issued the exploit). Responsible researchers should always give software vendors a "final warning" and 1 - 2 weeks notice before releasing a type 1 disclosure.
A researcher discovers that if you double click on a certain diebold ATM touch screen in the right locations, money comes out.
/. crowd would say that's perfectly OK.
The researcher then decides to send a detailed document on how to do it to all major press outlets without first informing diebold. You see, the researcher works for a competitor, and the point of the research was to hurt diebold's stock value irregardless of the harm it would do to the financial industry.
Is that responsible disclosure?
Most people would think not. You'd at least tell diebold and let them have a chance to fix it before telling the world how to do it.
Now, replace diebold with Apple, the ATM machine with FairPlay (the money being copyrighted goods), and the researcher with DVD John.
Now most
The responsibility to the public is to minimise their risk.
Full disclosure increases risk. Malicious people who would not have known about such vulnerabilities often learn of them through full disclosure.
However, by keeping quiet about a vulnerability, you are enabling the vendor - who does not necessarily have the public's best interests as their primary concern - to put the public at further risk by not fixing these vulnerabilities promptly.
The real question is how long a vendor should be allowed to sit on a vulnerability without fixing it before they should be considered derelict in their duty to the public. Where is the line drawn between the two extremes?
Naturally, this varies from vulnerability to vulnerability, and from vendor to vendor. A vulnerability that is the result of a badly designed architecture is going to take a lot longer to fix than a simply buffer overflow. A vendor that has billions in the bank and an army of programmers should be able to fix things quicker than a vendor that has a handful of programmers.
So really, there's no single correct answer. The answer is always "it depends". The vendor should have enough time to be able to fix the issue promptly, but they shouldn't have enough time to simply put it on the back burner. Unfortunately, the only people capable of determining how much time is reasonable are the vendors themselves.
I think that as long as they are responsive to the discoverer, and don't take the piss by taking years to fix it, the benefit of the doubt should be given to the vendor. But at some point, with some vendors, it's likely that the discoverer will have to use their judgement to decide that the vendor is stringing them along, and it's in the public's best interests to increase the pressure on the vendor with full disclosure.
Bogtha Bogtha Bogtha
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.
But when my holes are open I close them quick before someone shoves something in there... like a Trojan.
Why not wait until you have a solution to the security problem before disclosing the problem?
Granted, I understand that closed-source must make this difficult, but even so, a researcher who understands enough about a system to break it must surely understand enough to come up with a workaround.
I know it is a lot easier to find flaws than fix them, but unless a researcher is willing to offer a fix, disclosure of security flaws doesn't do much to help:
Sometimes I wonder if those who inappropriately post security vulnerabilities are more concerned with self-promotion than actually helping out the community.
The society for a thought-free internet welcomes you.
It's difficult to put a deadline to it for a variety of reasons. Yet when companies like Oracle take years to fix security holes, clearly something has to be done. There is a point at which all the excuses fall apart and they're just smothering the security flaw.
Responsible disclosure has no real benefit to the end user. It may stop some percentage of big outbreaks of worms but it doesnt in any way make life for admins guarding sensetive information a bit easier. From what i have understood many exploits are used by crackers long before they are in the wild. That is, many networks and servers are broken into and gathered for intel long before there is a patch, sometimes even for years.
Responsible disclosure only lenghten the period for the crackers in wich they can use their exploits for real cracking. It gives at best a breather for software manufacturers to drag their ass. It also doesnt promote real testing and auditing of software before its shipped. I would as an end user much prefer more tested software, that includes OSS thank you very much. Current release cycles is way to short to give any time for testing.
HTTP/1.1 400
(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 trouble with secrecy is that there is no way of knowing who knows the secret. Just because some researcher told you doesn't mean they are the only one that knows.
If "Responsible disclosure" is only a propaganda term, why would Mozilla and other popular open source projects use them. Why do they block access to security issues.
If a hole exists, it exists, however not everyone (including hackers) knows about it until it is published. Holes exist nowadays for years, some flaws for instance in NT 4.0 are discovered now 10 years later. Software is waay to complex nowadays it is good bet to take that unless published most holes will go completely unnoticed, until some other security firm after 100s of hours of research will find it.
Oddly enough, I used to work on a project for a huge company where this happened. We had a large search-engine like project that was running much slower on a 16 proc Sun box than I thought it should. I noticed that 40% of our traffic came from the same 5 subdomains, representing over 10 - 20,000 hits/hour. "Who uses a search engine that much?" I asked.
Me: Something fishy is going on here.
Boss: Report your findings to the project team.
Project Team: Hmmm... that is fishy
[weeks go by]
Me: Something fishy is STILL going on here.
Boss: Report your findings to the project team.
Project Team: We don't have a disclaimer on our site that restricts the number of hits/hour. Contact legal.
Legal: We'll get back to you.
[weeks go by]
Me: Something fishy is STILL going on here, and it's getting worse!
Boss: Report your findings to the project team.
Project Team: Did legal get back to you?
Legal: We'll get back to you.
[weeks go by]
Me: Something fishy is STILL going on here, can I at least block them via hosts.allow or a firewall?
Boss: Report your findings to the project team.
Project Team: Hmmm... I don't know. Did legal get back to you?
Legal: We'll get back to you.
[weeks go by]
Slashdot: "Your search engine is a known hack to alter page rankings at Google!"
Slashdot Commenters: OH yeah, that's been a problem for a while. That damn company!
Me: YIKES!! SLASHDOT has posted our company name in connection with fraud. AGAIN!
Boss: FUCK! DO SOMETHING! This is a PR nightmare!
Project Team: FUCK! DO SOMETHING! This is a PR nightmare!
Me: Luckily, I have already written a script to do so. Give me a sec--
Legal: We have shut down all admin access to this box, because there was this article on Slashdot, and we need to see if it's been hacked. We've opened a ticket.
Me: GAAAAAHHH!!!
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.
I don't mean to pick on you specifically, but I'm not so sure we can ever agree on any arbitrary but fixed number of hours/days/weeks, without at least some verification of the security report itself. What if some self-proclaimed security "expert" reports to a vendor, "You have a major security flaw in product X version Y.Z" and nothing more?
Certainly this is stretching the truth to prove a point, but it might take at least a few days to even reliably replicate a complex security hole, especially if it is some sort of timing and/or concurrency attack.
Not every so-called "expert" out there who manages to find a flaw deems it useful to provide exact details regarding said flaw, and I'm sure there are at least some who pride themselves in leaving the details as a proverbial exercise for the reader.
http://www.eeye.com/html/research/upcoming/index.h tml
Looks like certain software companies sit on the issues for a long time (and are still sitting on them).
In their defense, most of the KNOWN viruses/worms/trojans are written after the public release of the patch when the less capable people can see the exploitable code.
The discoverer of a flaw owes nothing to any vendor. His obligations are to the users of the software and the public, not to the vendor.
It may benefit the users to inform the vendor first. It would be polite to let the vendor know when the information will be released to the public.
The discoverer isn't responsible for the flaw. The vendor is. The discoverer isn't responsible for fixing the flaw. The vendor is. The discoverer isn't responible for exploiting the flaw, criminals are.
Hiding the flaw doesn't make it go away. Vendors should stop trying to blame everyone else for the fact that they, the vendors, have exposed their customers to damage and loss.
Let us suppose the researcher (R) reports a security hole to the software producer (let's call them M). ... who also have more items in their priority lists. In a case like this the timescale is probably approaching a month for a "fairly high priority" problem.
First the report on the problem has to get to someone who has the knowledge to investigate and fix the problem. In a large organisation this is likely to take several days. It then has to be prioritised in his workload (Hey! you think there is only one problem?).
Next he has to verify that the problem exists (hopefully R has provided a repeatable example).
Then comes the first difficult part - identifying the root cause of the problem. If it is a buffer overflow this might be easy; a tricky combination of factors in a single module may be more difficult; an underlying design feature or a clash with an important usability function is going to cause major difficulties.
In the simple cases an initial fix may be possible (and right first fix) within hours - but will then have to be tested against the whole test suite and documented. We are, by now, probably already a week after first report for anything beyond a "damaging exploit in the wild" event.
For the complex, but limited in scope, hole much more is going to need to be done. Several people need to understand the problem and possibly redesign the module. The replacement code will take longer to get right and to test. It probably also needs to be done by the more experienced members of the team
Now think about the clash of design principles type of problem - in practice this is probably going to need a fairly ugly hack by very skilled programmers (A major redesign is rarely viable for widely distributed commercial software). How long do you think this is going to take?
Oh wait...I'm one of those freaks that sees software licensing as an ethical issue as well as a technical one. Oh, silly, zealous, religious, extremist me...
Please forgive me for caring about society as a whole.
I'm a full disclosure sort of guy.
I believe in people taking full responsibility for the software they use -- hence I use OpenBSD.
I'm happy when I read about a worm destroying Windows and costing them time & money: if they want to be irresponsible and run that stuff, it is important that they get some negative feedback, else they are likely to persist in falling victim to keyloggers and other malware.
I'm one of those, "it has to get worse before it gets better folks."
http://www.thebricktestament.com/the_law/when_to_
If a company is not responsible for the security flaws it put (or failed to fix/avoid) into products, why should someone be responsible for having disclosed them to the world?
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
Microsoft publicly chastises security researchers who don't follow its rules.
It's simple. Researchers should form an organization and make their own rules regarding disclosures. Then follow them to the letter and expect the companies to do the same.
Both parties would fall under the umbrella of the group and have one set of procedures/rules for all. Not seperate procedures/rule for each company.
Of course doing this is the hard part. It could be funded by the major players. It would save them face and streamline things too.
Of course could they live by one set of rules? I doubt it.
When was the last time Microsoft took 6 months to fix a critical security related flaw?
why not just combine the two approaches? Just report the exact flaw to the vendor, and report to the public that you've reported some unspecified flaw and they might want to look into it.
Why do my serious comments get modded "funny"?
My first reaction was that you were a troll, but the justification that follows it is actually well-stated, so I'm going to take a chance that you're not just trolling as an AC.
As such, I think the point above is fundamentally flawed because it makes one large assumption, namely that you yourself discovered the flaw. Using your logic, if you didn't discover the flaw, but a like-minded individual did, your clients' machines won't be fixed by you or patched by the vendor.
How exactly does this let "market forces do their thing" in any way? Basically this causes an artificial information imbalance, which, in addition to being heresy to the "information wants to be free" crowd, specifically impede the very market forces that would help consumers make informed decisions.
Microsoft only assumes liability up to the purchase price of the software, or you can't use it legally.
Most security holes are exploited for acess to money through identity theft, theft of money, or exploitation that destroys someone's credit or means to make or keep money.
The FBI, the Department of Justice and the Secret Service (surprisingly, it deals with certain kinds of theft and fraud) should receive notice whenever a company is notified of a security hole. This information could help them track people exploiting the hole, if they know what to look for. It would also be a means of adding pressure to the software maker to fix the security hole as expeditiously as possible. People who get burned because of this hole could refer to the FBI/DoJ/Secret Service notification date as a basis for suing a software firm that wasn't quick enough fixing a hole.
He said "onus", uh-uh-uh.
Responsible disclosure: inform the vendor privately, give them enough time, say, 1 month. Then, if they just sit on it and hold meetings with thumbs up their asses, doing nothing, you go public with the flaw.
The point of going public at that point is to lessen the impact of blackhats exploiting the security flaw before a fix has been provided.
If a vendor does not do anything to the flaw within 1 month, they're not going to do anything at all. And in that case you might as well go public, because there's a good chance some EVIL HAXORS have learnt of the same security flaw and are now breaking into shit without the GOOD PEOPLE finding out.
Any more questions?
There are several issues.
-Not disclosing the vulnerability is a bandaid. If one person found it, others can as well. Not disclosing vulnerabilities can -never- be viewed as more than a temporary delaying tactic. Once a vulnerability is known, we can picture a clock that starts a countdown, ticking off the days to an actual exploit.
This countdown starts when the vulnerable system is -released-, not when researchers discover the vulnerability or the vulnerability is discussed openly. Absolutely no one can predict how long we have. For some vulnerabilities, the researchers discover it -after- the black hats, and -one day- is too long to wait for them to report it. The vendor is not necessarily the best judge of this time limit; some vendors seem comfortable with waiting up to 2 or 3 years to release a patch.
-Not disclosing the vulnerability, for a brief time, so that a patch may be created is reasonable. What makes it highly controversial is that no one agrees on what is a reasonable period of time. As indicated above, there is no single right answer to "how long is too long"
-For most vulnerabilities, the issue is not as simple as patched versus unpatched. For -many- vulnerabilities, various workarounds are possible. Proactive system administrators are safer if the vulnerability is reported immediately. Passive or reactive system administrators are arguably safer with delayed reporting. However, the number of systems that fall to vulnerabilities patched months or years previously indicates that delaying disclosure for the benefit of these admins may be a self-defeating tactic.
-Many vendors have very large problems with their security responses. Often, patches disable some functionality or destabilize the application/OS. Other times patches depend on new versions of software, OS upgrades, or exchanging one vulnerability for another. Many people feel that these vendors -cannot- be relied upon to improve without a -very big stick-. Some people want to use immediate disclosure as that stick.
Comments?
An article by Mary Ann Davidson (CSO, Oracle)
Security researchers problematic bunch?
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
Step 1) Find bug.
Step 2) Write exploit
Step 3) Write fix
Step 4) Let vendor know about security flaw and show them the exploit. Tell vendor you want X amount of dollars for the fix within Y days or you will release said exploit publicly.
Step 5) If vendor doesn't put up the dough or produce a publicly available patch within Y days, patent said fix and disclose exploit to the public.
Hmm. I seem to do this "reveal the flaw only to the author" method. The "author" gets annoyed with me if I tell anyone else.
" The best security is to inform all users once a flaw is discovered."
No, it isn't.
The best security is for software vendors, security firms, and AV software providers to share information and work cooperatively to get AV updates to end users (average Joe Sixpack) while the OEM vendor works on a patch--and keep it out of the "public" eye.
Your internet-connected mom/gandmother/uncle/aunt would never know they were vulnerable anyway, even if the story was on the front page of every newspaper. Unless their machine is set up to automatically check for and install AV and security upgrades, the machine is proably already compromised. If it is so set up, they are covered.
Meanwhile, the script kiddies (as opposed to true criminal hackers) will never be the wiser until the AV updates and patches have already been out for quite a while, and therefore most if not all responsible users are protected.
Ignorance is curable, stupid is forever.
The majority of worms,trojans, etc that do real damage are not written by security researchers.. they're written by thugs that use someone elses research and attach a payload to it.
The goal of responsible disclosure is to reduce the aggregate damage of a security incident.
We've seen that in the past, malware has been written by adopting the code/info/techniques in the bulletin, sometimes even the info-light ones released by MS!, and has caused considerable harm.
Yes, it is true that _somebody_ might secretly know a vulnerability exists, and might choose to exploit it for the purposes of a targeted attack.
OTOH, when you put code/pseudocode out there before a patch is ready, it is highly likely that _everyone_ will suffer from an undirected, general trouble-making type of attack.
Corporations that are the targets of precision intrusion are NOT living or dying based on 0-day disclosure. But the millions of home users and casual everyday users DO get _crushed_ when a worm/virus hits their machines.
The best thing for the internet, computer users at a whole, etc, is a disclosure policy that works to get the defects fixed in a timely manner and without making it trivially easy for malware authors to construct wide-spread destruction.
Full disclosure was the radical movement that finally caused companies to wake up, and for that, i appreciate its contributions. However, "idealist" is another way of saying "pretentious, insufferable, @#$head". The full disclosure movement, having finally gotten the attention it deserves, needs to shift pragmatically towards a reasonable approach that delivers the highest overall benefit, and that's what responsible disclosure is about.
You may argue about the details of how long it takes to get out a patch, but turst me, the idea that releasing full exploit code on day 0 is a good thing for todays internet is ridiculous. I'm curious to see an argument that suggests it is more appropriate and better than a responsible disclosure to the vendor.
My opinions are my own, and do not necessarily represent those of my employer.
in the security community for quite some time.
Rain Forest Puppy drafted a formal policy you can peruse here...., but if a vendor like Microsoft takes six months to a year to fix a flaw ...
Now, I'm not the Microsoft apologist of Slashdot, but I mean can we at least throw the names around of some other extremely bad abusers of this "sit on exploits/bugs and fix when we feel like it" policy?
Oracle and Cisco should also be admonished for their response time to fix exploits/bugs disclosed to them as well. Cisco and their Black Hat convention fiasco proves that MSFT isn't alone and really shouldn't be singled out (I don't want to debate the Lynn bug as being new or not).
Also, let's not forget that Zotob was patched before it was released in the wild, but users and admins failed to apply these patches in time even after SANS had raised the alert level to yellow the day before (and I don't want to argue about "we can't just blindly patch our machines", etc.)
Definitely, Linux, mySQL, Apache, the PHP CMS and forums community seem to be highly responsive to security threats and definitely, MSFT makes some very buggy, insecure software, but some impartiality would be nice every now and then.
Hagrin.com
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 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.
Now picture the one at fault to be Joe Blow working from his basement during his "free time" outside of the 65 hour work week at his real job. Class action lawsuits like this would kill open source completely.
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.
Or Joe Blow is now in prison, is fined an amount he can never pay, his credit, business, and everything is ruined. End users who could have received a patch if it wasn't for that "damned lawsuit happy group being so pushy on time limits" are left with an end-of-life broken product. Don't be so hastey to criminalize the innocent. Too many laws and lawsuits these days do just that.
Just another perspective....
Two roads diverged in a wood, and I - I took the one the bus load of girls just went down.
Give too little time to companies, and you'll be helping the blackhats. Give them too much time, and we end up with a phantom enemy that is surely out there, and the public isn't aware until it's too late (i.e. credit card numbers stolen, etc).
But I'd say a month's more than enough. Unless of course, a new (and unpatched) version of their software is going to be released earlier. In that case, i'd give the company a week max.
People seem to believe that until a vulnerability is disclosed publicly, nobody evil knows about it. This belief is unfounded.
These people that reports and reveals details on how to exploit a flaw in the software are a complete pain in the ass, they always say that they contacted the software author and they NEVER contact anyone and publish the complete stuff. Software authors will know about a flaw only after their software has being compromised all over the world.
These people, most likely non-ethic script kiddies should be erradicated, and all sites that publish their exploit should be considered a site immersed in the cracks/virus schene. Point.
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 ?
I use OpenBSD too, so don't start with me.
How can you be happy when someone else is suffering? It's not your grandmothers fault she uses windows. OpenBSD is NOT appropriate for "home users", and it's not designed to be, and it cannot ever be as secure as it is yet as functional as required for non-power-users.
Every operating system in use on PC's has security issues, even openBSD. OpenBSD is where it is because it's entire focus is security/correctness.
Security and correctness are NOT the most important aspect of general software development - if they were the only requirements, then a lead box buried in the ground would easily be more secure than openBSD. The issue is functionality vs security and correctness.
When there is something that works as well as windows for what people that use windows need to do, but has fewer problems, people will change to it in droves. For some people, that is Mac OS - although it has its own severe security problems - do you laugh when people with macs have to reboot their machines because of SoftwareUpdates ?
In any case - 0 day full disclosure hurts the majority of computer users. No amount of pain will convince them to stop using windows. If you want people to stop using windows, develop a credible alternative. Don't sit and laugh at people that don't have better choices available to them, and then say things like "i support people making life harder for windows users".
My opinions are my own, and do not necessarily represent those of my employer.
Quite frankly, we wouldn't have to speak about whos or whats. It is common sense actually to expect any purchaser of software to audit the systems it puts in place.
Which is one of the reasons we audit all of our software on our network, for our ERP and accounting to our Warehousing.
Obviously, you can't do this with proprietary software.
Too bad for you, you got ripped.
For us, we do our own security audits because we can, and because it makes sense to do so.
After all, the manufacturer of the software doesn't use actually use the software, we do.
Ironic that most places who write accounting software, like Microsoft, don't use the same software they write to do the accounting to run the business.
We the customer are in the position to fix bugs, correct security flaws because we use the software.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Reasonable notification time shouldn't be more than 30 days - if a company has a longer lag than that to fix a security flaw/problem, then their business model is flawed.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Which statement describes more machines connected to the public internet:
- computers belonging to home users or uninterested business users, with no training or expertise at securing and patching computers
- computers that are
-- managed by security experts
--- that, given a full disclosure statement, would know what to do to mitigate their protected assets against the vulnerability and could do so within 24 hrs,
-- given the above, are running machines configured such that they were actually vulnerable to the issue
Responsible disclosure is better for more computers and more people. Adminsitrators smart enough to benefit from 0 day disclosure are smart enough to not need 0 day disclosure because of defense in depth. Everyone else suffers from 0-day disclosure.
Compare the # of incidents of clandestine, targeted attacks vs the # of incidents of machines compromised by today's worm-du-jour, written by someone based off of a vulnerability report, usually with working code.
My opinions are my own, and do not necessarily represent those of my employer.
... to dictate to software owners when and how they should fix security flaws. I like how the guys at hexview.com do it. They submit all techical details about the flaw to the vendor and give them 24 hours to respond. Vendor is expected to reply how and when the issue will be resolved. If there is no reply or the vendor is not cooperative they just release all details to the public. To discourage vague answers saying that it'll be put in a queue and resolved someday, hexview folks set another 30-day non-negotiable deadline and the countdown begins.
I have actually been in the middle of this before, having found a way to passively grab billing information from a larger online subscription-based game. A colleague and I built a complete technical description of the issues, theoretical "worst case" possibilities, as well as a working proof-of-concept exploit, making it clear that we would wait for a suitable fix to be in place before we would release details. We got an email back within several hours from one of the lead programmers who wanted to do a conference call but when we agreed, we never heard from him again.
We were then contacted by a manager-type that this 2-year-old hole was already being fixed. We offered our expertise to review their solution but they weren't interested. Instead, 2 special agents from the FBI showed up at my work to interrogate my involvement in felony extortion.
After a 4 hour long interview session (during which I was escorted to the restroom and watercooler by an armed agent) and I provided all correspondance and source code, they left and never came back. The best part the WTF? look I got when I described how this company was transmitting credit card information XORed with a cleartext seed transmitted in the previous packet. Second place had to be the "Why are we wasting our time here?" look I got when I explained the only credit card information I have actually seen was my own.
The hole was silently fixed in a patch distributed weeks later, and replaced with another algorithm which was also easily exploited. Again, we went through the entire process of creating documentation and a working exploit and sending it to the company. This hole was patched months later.
The company's response was always hostile at best, which I found odd considering we were trying to help them protect their customers. They never disclosed (publicly or to the credit corporations providing merchant accounts) that there was any issue.
American Express has an extremely specific policy on security, and have a minumum requirements policy which all online merchants are supposed to adhere to. They also require you to notify them if security has been compromised. California law also states that card holders must be notified if their account information may have been compromised. Apparently it's not a big deal if noone abides by these rules.
When the company is unresponsive in resolving security flaws, I feel that disclosure is imperative to allow users to take their own precautions to protect themselves. I'm not malicious, but I imagine that there are a lot of people smarter than I am that are.
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?
Joe Blow should know better than to run a software business next to his 65 hour work week. Oh, Open Source you say? You mean like the kind that has no warranty, no fitness for a particular purpose and no monetary value whatsoever being exchanged?. Don't worry, Joe Blow hasn't sold a thing to anyone, he is safe.
The best security is to inform all users once a flaw is discovered. The users can then take their flawed web clients, flawed routers, etc. off line. That action immediately prevents the problem.
Though I suspect you intended to imply here that the "information" supplied to the users should contain a detailed description of the vulnerability, let me just point out that a vendor could just as easily send out a notice stating that a critical vulnerability was just discovered, and provide mitigation instructions.
This certainly gives the black hats enough information to start probing the impacted service but doesn't go so far as to turn the event into a race (thereby rushing a riskier short-term patch instead of allowing the vendor to produce a well-tested one).
If you're a software vendor, simply apply the formula.
Jack Says: Take the number of copies in the field, (A), and multiply it by the probable rate of an exploit being found, (B), then multiply the result by the average out-of-court settlement, (C). A times B times C equals X...
If X is less than the cost of producing and releasing a patch, you don't do one.
"Ein Volk, ein Reich, ein Führer." -Adolf Hitler
"We are one Nation, we are one People." -The One 'leader'
Let the manufacture know of the issue but if the issue is not patched within a week let the world know of the issue but not the exact details simular to what this guy did and if it still has not been patchedwithin a second week then let the world know the full details so that we can protect ourselves from the issues. I would expect this from both open and closed source software.
Do you REALLY audit every piece of code that you run? The entire Linux kernel, for instance? I don't believe it. And even if you make a good effort to get most of the network-exposed code audited, you can never be sure that you're actually finding vulnerabilities--can't prove a negative.
Disclosure of exploits and fixes to the author is like any other OSS bug-fix submission: Yes, you're doing work that you're not getting paid for. But at the point where you've already done the work, your time is a sunk cost. Why not inform the author (nearly zero cost to you), and do everybody else in the world a favor? Sure, you lose that "competetive advantage", but you also have to maintain all your own patch sets against published versions, which INCREASES the amount of effort you have to spend. If you have a secret bug fix, you have to re-work the patch every time a new version comes out, so you can use all the other bug fixes that you didn't find that are in the published version.
Also, a secret bug fix may not be a fix at all. Isn't it better to tell the authors, and let people who know more about a particular software package than you determine whether 1) it helps, 2) it doesn't cause additional problems, and 3) it's the best way to fix the problem?
IN short, I believe that your hubris actually makes more work for you, and will eventually come back to bite you in the ass when you break something in the process of trying to fix it yourself, or you screw up your source trying to maintain your precious secret patch sets.
At that point, I just hope you're not working for me. But you sound like an arrogrant control freak, anyway, and we don't hire people like that.
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?
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?
This is a bullshit question. I don't want to hear another single question like this until we have ethical accountability from the corporate execs who are running the companies that are bitching about security disclosures.
Yesterday I read the article about Steve Ballmer ranting like a psychopath calling for the head of the competition. I sent that article to some business exec friends of mine and heard back, "There's nothing to see here - most execs of large firms are like that." That fits in very well with everything that floats to the service.
So you know what? Fuck 'em. When they start playing the game like rational, ethical adults, we should start listening to their ethics requests. Until then, we as a society go miles beyond their standards, and have nothing to be ashamed of.
Stop-Prism.org: Opt Out of Surveillance
2) use my preferred approach: fix your clients' copies of the program, and otherwise keep quiet. Consider it a competitive advantage when the next Apache/SSH/PHP worm hits.
That's not very neighborly of you. Many other people can benefit from that knowledge and yet you use it to your own advantage, and don't even let the rest of us know we are vulnerable?
Why would you do this to the rest of us?
-molo
Using your sig line to advertise for friends is lame.
You may know me as Paul from Greyhats (http://greyhatsecurity.org/oldsite), or something similar (if you keep up to date with security issues). I used to have the same view as Ferris, but after Microsoft got me involved with the security community outreach program, my mind quickly changed.
Since the Microsoft security push, Microsoft has taken more than a couple months to fix a bug on only a couple issues, and seriously, I could name more than a few flaws (still private) that I found in Firefox and reported to Mozilla months ago.
The reason that Microsoft takes a while to patch issues is that they have to release a single patch that encompasses all of their products at once. They do this so that corporations that use their products can plan ahead for updates (these things cost money to install on big networks).
Security testing in Internet Explorer, which is where I usually focus my effort, has become extremely difficult (note when I say security testing, I meen testing for serious/critical vulnerabilities). Microsoft has come a long way as far as security, and I predict that they will only get better.
How about if he offers a box set (like many Linux distros do)? Then he's sold something, the box set.
Tao says : Morality is the penury of faith and trust and the beginning of confusion.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Do you REALLY audit every piece of code that you run?
Saying that I can't audit EVERYTHING (which is true) is not a good reason to disallow me from auditing anything.
It is also true that there may be very obscure bugs in the code. However as a practical matter it's pretty easy to audit something like phpBB and find the low-hanging fruit, surprise surprise, it gets exploited a few weeks later.
Think of the analogy of the two guys running from the lion: "we can't outrun this lion" .. " yeah but I can outrun YOU"
Disclosure of exploits and fixes to the author is like any other OSS bug-fix submission
I treat security issues differently than other patches.
At that point, I just hope you're not working for me. But you sound like an arrogrant control freak, anyway, and we don't hire people like that.
That's exactly the kind of person you need to keep a network secure. :-)
not another Fight Club quote.
Consider the following examples, all culled from roles I've worked in. Open source vendor A doesn't bother to respond to a remote hole in a webmail application, whilst open source vendor B patches a remote hole in their VoIP application immediately. Closed source vendor A forwards our advisory regarding a remote hole in a monitoring tool directly to the main security mailing lists, whilst closed source vendor B sits on a remote hole in a banking application for months. So how does responsible disclosure fit in, in these circumstances? Ultimately it doesn't, security companies must be willing to publish and be damned in order that the vendor Bs of the world are forced to adapt. At work we give 30 days for confirmation and fix plan from vendors, privately I work on a 14 day cycle.
Tim Brown
What if someone were to come up with a way to trivially factor the product of two very large primes? This would pretty much ruin RSA. What would be a responsible level of disclosure for something like that? How long until a public announcement without the method? How long until a public announcement with the method? How do you ensure someone doesn't try to snuff you to be sure the method never gets out?
now we need to go OSS in diesel cars
The best security is releasing the patch as soon as the first *WORKAROUND* is identified - for example, a windows update that turns off IIS or SQL Server or the entire OS or whatever the vulnerable package may be. Later, when they fix the problem at their leisure, they're welcome to push out an update the re-enables this service. Customers who care about security should have the option on which systems to enable these turn-off scripts (any app where security is more important than uptime); or as with any update, they should be free to ignore them. This takes the reasonable time-to-disclosure down to hours, because the default disabling "shutdown now" update script that protects against any security hole already exists.
Paul Clark's full disclosure debate bibliography doesn't seem to have anything from 2005 but has most of the important articles on the subject.
If a particular model of microwave oven had a design fault which could cause the magnetron to turn on while the door was open, the manufacturer would have to deal with it straight away {and not in six months' time with users dropping like flies}. If a particular model of gas boiler had a design fault and could explode or leak water under exceptional circumstances, the manufacturer would have to do something about it {and not try to silence the person who tried to warn the world about it}. If a particular model of car had a design fault where the throttle would open wide or the brakes suddenly try to engage, the manufacturer would have to respond {and not try to pretend that the problem did not exist}.
It should be no different with computers. If there is a security flaw, the vendor should act immediately to do something about it -- first warn users that the problem exists, and then get to work on eliminating the problem. And this should be done as soon as possible.
The Open Source community generally responds immediately to security reports. Closed-source vendors should not be allowed to use secrecy to get away with selling an imperfect product. I believe that software suppliers should be held accountable for their products -- either by making the source code available for inspection {hence moving it more into the realm of goods supplied in kit form, where the purchaser has some input into the construction and therefore some responsibility for the eventual performance -- like using longer screws and adding extra bracing to a piece of flatpack furniture}, or by offering a guarantee of performance if they insist to keep it secret.
It's also important to remember that (1) good guys outnumber bad guys and (2) if you discover something, the chances are that someone else has already, or is about to discover it.
Je fume. Tu fumes. Nous fûmes!
People who can't secure their computer shouldn't connect it to the internet
Consider yourself disconnected.
You run openBSD. OpenBSD has had security vulnerabilities. Ergo, you shouldn't connect your openBSD mchine to the internet.
If openBSD was perfect, it wouldn't matter what the rest of the internet was doing - why does oBSD care if someone is trying to DDoS it? Doesn't it have the "perfect-filter" technology that automatically hacks upstream routers (which are insecure since they dont run openBSD, and which by the way, ought to be disconnected from the internet) and null-route sources of DDoS traffic? I mean.. being victim to random internet traffic sounds pretty insecure to me..
I understand being frustrated that other people have insecure computers, and that the internet is a "community" resource. Hopefully, you realize that your statements/position are ridiculous and self-contradictory. Wanting them to suffer more doesn't make your life better - and certainly not theirs!
My opinions are my own, and do not necessarily represent those of my employer.
There may be no single silver bullet to this problem, but I'm pretty sure that the GP's overconfident isolationist approach is not among the top alternatives for the community as a whole -- and, arguably, perhaps not even for himself.
$0.02,
ptd
I'm an animal lover -- they're delicious!
The responsibility of computer based security is a very complex question.
This being said, the responsibilty cannot be assumed by the software developper/publisher alone like mentionned by several posters here, unless, maybe, and only MAYBE, if the purpose of the software is specifically to protect the user from unauthorized access/use of ressources (firewalls, nat routers, etc...).
Security vulnerabilities will exist as long as software will exist and malicious hackers and script kiddies will probably always be around to cause trouble to technology's legitimate users.
The costs to develop a software with 0 vulnerabilities are infinite, so you have to find alternate ways to minimize the problem.
Just like in the case of terrorist attacks or natural catastrophes, there is a point where additionnal investments in a software's security will only produce a very marginal decrease of the risk levels, and are thus, a waste.
This kind of problem becomes an opportunity for some companies, like insurance companies who base their business models on taking risks on your behalf, a service for which you will pay a premium either monthly or annually.
At this point, software use could probably become like any kind of activity that involve risks. If your company use technologies which are statistically more likely to be breached, you'll face higher premiums. Inversly, if you employ a certified and experienced network administrator, your premiums would be lowered, etc... So a part of the costs would be assumed indirectly by companies, in the sense that if a company dedicates more ressources to the security of it's software than it's competitors, it will be rewarded by a more widespread adoption, due in part to the lower costs in insurance.
Of course, this solution raise a number of additional issues, but I certainly think the insurance companies are much more geared toward solving this problem in the economy than software companies are.
Software developpers should focus on building useful software.
Are you retarded or something? 100.000% vs. 100.00% vs. 100.0%? WTF?
Parent is insightful and funny... Funny, sure, but Insightful? More like Troll.
/., I may end up getting modded to -1: Microsoft Sympathizer. I just don't like to hear knee-jerk bias get called "Insightful".
Honestly, there is no shortage of reasons to bash Microsoft's business practices. It's practically a national pastime in computing circles. Do we really have to take an argument that applies to 80% of the software companies out there, wrap it in specious hyperbole, and then call it Insightful?
From the moderator guidelines:
Insightful -- An Insightful statement makes you think, puts a new spin on a given story (or aspect of a story). An analogy you hadn't thought of, or a telling counterexample, are examples of Insightful comments.
I'll give credit where credit is due. Parent had a great one-liner. Wonderful use of wit! Zing! I just can't see how this comment "puts a new spin on a story" with a one line comment that basically repeats every other anti-MS sentiment in this topic.
Is Microsoft at fault for sitting on security holes when their marketing and business departments thought it was inconvenient? Probably. I wouldn't be surprised. Is there any evidence that their delay has been for those reasons, and not just because they have a giant inefficient juggernaut of a development team that takes forever to put out anything? No evidence that I've seen. "Never attribute to malice what can be adequately explained by red tape" -- Paraphrase of Occam's Razor.
I think the question I keep asking myself about the whole Responsible Disclosure question is "What would I do in their place?" Everybody seems to be placing themselves in the position of the white-hat that has just found an exploit. What would you do on the other side? If you had just released your masterpiece and it has a security bug, would you prefer to hear the exact details of how to compromise your software from an article on slashdot? I'd be pretty horrified. I can relate to the software company's sentiments. I've been there.
I can also see the argument for full-disclosure, made very well in other comments. I can relate to the white-hat professionals, because I've been there too.
I'm not saying there aren't people out there who drag their feet rather than patch their software. What I'm saying is that they don't all work at Microsoft.
Of course, this being
> The only 'responsible disclosure' is full and
> immediate disclosure.
This will make security worse.. Consider:
a white hat found a security problem and disclosed it.. What disclosure does is this
1. It forces the software maker to release a patch as quickly as possible (good)
2. It allows black hats to exploit it (bad)
The problem is that under nearly all scenarios 2 will happen faster than 1: blackhats do not need to worry about reproducing the exploit/evaluating the impact/QA/Xplatform compatibility/backward compatibility/informing the users/users evaluating the impact)... So even if you have an ultra responsible OEM, blackhats will still be there first! Pretty much guaranteed.
Yes responsible disclosure should include eventual full disclosure...But immediate disclosure is a bad thing...
What should be an acceptable waiting period? My guess is 1-3 months...But do disclose the waiting period as a part of full disclosure...
Slashdot report bugs to you.
> longer dealing with computers but with people
> and if you piss them off to much they will be
> less then helpful.
If you ever find yourself being accused of not practicing responsible disclosure you can take comfort in the fact that you cannot be responsible for everyone's needs. The term "responsible disclosure" doesn't include the part about who you are supposed to be responsible for, that's up to you to decide.
In my humble opinion, the correct way to disclose a bug is however you feel like doing it. You found it. You don't owe anybody for that. Maybe you believe that the fastest route to a more secure and reliable world of software is if people who choose to use certain software are punished as often as possible so that they switch to software written by a more responsible party. Who knows? Maybe it could work. It is definitely not immoral or irresponsible to believe this since we don't know what does work. If there was one obvious true way to make a hole public (or not) that had no ill effects then everyone would be doing that already. duh.
If a researcher, with no prior contact with the vendor posts a vulnerability out of the blue then the people who work at the vendor are going to be pissed. They are going to call the researcher "irresponsible", but that's only because they have to maintain a certain amount of class. They really just think he's an asshole because he is going out of his way to make things harder than they need to be for the developers and the customers who use the software.
I do not think many researchers are acting this way.
On the flipside, when researchers contact a vendor in good faith and that vendor treats them badly then it is unreasonable for the vendor to expect any more good faith efforts from that researcher.
As you so aptly pointed out, having tact is key. If the researcher does a vendor the courtesy of giving advanced notice, and he is open and honest about his motovations and expectations, whatever they are, then I say he is responsible.
examples:
A researcher who found bug by fuzzing, currently has _no evidence_ that it is being exploited giving a heads up to the vendor:
"hi I just found this remotely exploitable heap overflow in WizBang. All versions starting from 2.1 are vulnerable. You can reproduce this bug by blah blah blah. I plan to discuss this during my presentation at PacSec, a security conference that focuses on new research which is being held in Japan on November 15th. You should make sure you have patches ready before then. let me know if you need any more info."
It doesn't matter at all if the vendor really can't fix the problem before then, because it is a major design flaw requiring huge rewrite that will screw over the release schedule for the next 6 months. The vendor may say this and try to stall, then call the researcher "irresponsible" when he follows through and goes public, but it's nothing more than selfish whining. When someone who you don't even know offers you something highly valueable for free you are in no position to start making demands. It is utterly mind boggling how certain companies try to justify behaving this way.
In this example the researcher is being responsible for himself and his career by making it known to vendors who believe they are ultimately responsible for finding their own bugs that he would be worthy of hiring. Or he's making it know that his company has smart people who can find and exploit bugs, not a bunch of monkeys who charge money for running nessus. Either one thing that sure ISN'T his concern is making sure the vendor can patch in time. No amount of vendor temper tantrums can force him to take on that responsibility. How is it even possible to be responsible for the actions of a bunch of programmers who don't even work for you???
Here's another example of responsible disclosure that's sure to draw flames.
A couple
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.
Try reading the Windows EULA some time...
For the love of God, please learn to spell "ridiculous"!!!
Whoa, cowboy. There are no morals involved in this. At most, there are ethical considerations.
Actually, that's perfectly legitimate, as any high school student who's gone through the torture called "sig figs" can tell you.
The fixed number of digits after the decimal point implies that it's rounded, and is accurate to that level of precision. 100.000 is more precise than 100.00.
There are 11 types of people in the world: those who can count in binary, and those who can't.
Many other people can benefit from that knowledge and yet you use it to your own advantage, and don't even let the rest of us know we are vulnerable?
Why would you do this to the rest of us?
It's called "Capitalism". Screwing everyone else is a pretty normal business practice.
All disclosures and notifications should be done anonymously, using an uncustomized publicly released live distro (like KNOPPIX, ubuntu or mepis), (this insures no mail headers unique to you) several anonymous remailers and a resterant's public wifi connection. That way the vendor won't who to threaten.
Also use method 2.5, QUIETLY fix your client's applications, then release all info anonymously.
except that it's pointless in this case since it would imply that the percentage is actually more than 100. what the idiot probably meant is 99.9% vs. 99.99% vs. 99.999% etc.
good job defending idiocy with some "high school torture" without even thinking about its relevance.
No, anything from 99.995 to 100.00499.. would round to 100.000 at that precision.
I agree that 99.9 etc would have been clearer though.
Is the GPL requirement to publish source code for security patches an impediment to security? I'd guess there would be a window of opportunity for attack between the release of patches and the patches being applied to systems.
Would it be better if the GPL allowed for a short period (a couple of weeks?) between the binary and source of security patches being made generally available? If so, should there be a requirement that all listed copyright holders (for example) be provided with the source at the time of the binary release? Or would all this just cause more problems than it solved?
Talk to the vendor ASAP of course. Also talk to accredited researchers so they can provide protection even if the vendor chooses not to.
As soon as there is any indication a black hat might know of the vulnerability, disclose the risks and any workaround, similar to what MS does a few days before patch day.
As for disclosing the actual details before there's an exploit in the wild, that's very risky. You, as the person who has the knowledge, have to make a risk assessment - is the world better off if this is made public or if it is put under wraps. Once you've made that decision, give the vendor a reasonable amount of lead time so they can mitigate the damage your publishing will cause.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
If Microsoft and the other software firms lose a few costly lawsuits over this issue, watch the conflict between security researchers and the software firms disappear. Yes someone is going to tell me the contracts and other express consent agreements indemnify the software firms. And I can tell you many times these clauses / agreements are not worth the paper they are printed on. If someone can elighten me further on this, or indicate I am incorrect, please do so. Havent been involved in this area of the law for a long time.
I recently found a security flaw with an open source package I use. I notified the developer and never heard back. It has been three months.
This week I may have the time to actually write a patch to correct the problem (which seems to be a serious design flaw in the authentication system)... Once this happens I will send the patch to the developer. But at this point, I will only give him a week or so to respond to this email *because I never heard back on my previous alert.* If that doesn't work, I will send the vulnerability and the patch to various security-related email lists and make a full public disclosure.
The nature of this vulnerability is very serious. An attacker which has a valid account (or has compromised an account) can literally log in as any user on the system simply because the developer did not check the credentials properly. Exploiting the attack is trivial (and essentially obvious) and I suppose it is just due to the fact that the software isn't that popular yet that this hasn't been a real issue yet (that we know of).
I feel very torn about it. But I am very concerned that if I don't make it public, it simply will never get fixed.
LedgerSMB: Open source Accounting/ERP
a windows update that turns off ... the entire OS
That would be ideal.
The biggest gripe I hear from security researchers is that if they send in details of a flaw they get a form email at best and then no further information. In those kind of circumstances I'd say they should give the company in question three months - there can be few flaws that would take longer to fix if you're a large software house. At the end of that period send another email giving them a week to explain the situation and then publish. I dread to think how many major software packages have flaws classes as low risk by the coders and ignored. There's a lot of people looking these days.
I discovered the other day that some people, when they talk about "responsible disclosure guidelines", actually have a specific document in mind - but can't be bothered to include the URL.r t.pdf
The document's title is "National Infrastructure Advisory Council - Vulnerability Disclosure Framework - FINAL REPORT AND RECOMMENDATIONS".
Here it is: http://www.dhs.gov/interweb/assetlibrary/vdwgrepo
Lets look at some of the things you quoted - apache, php. Both relatively large, complex pieces of software and open to external (and internal) attack. Your comment of "Saying "it's okay" to write software with security holes, because shucks, some kind soul will fix it for you." Is rather misguided. I doubt anyone on those projects is deliberately writing bad code, they will be trying as hard as they can. On something large and complex it is inevitable there will be bugs, some of those will turn out to be security related. People are not perfect, there will always be something that a single individual will miss: I'm sure, if you wrote a large piece of software then I or other ./ers could find some faults (just as you may be able to with software I wrote). No matter how good you may think you are at programming you *will* make a mistake (I'm assuming a degree of arrogance given the "since maybe 95% of the coders out there can't code properly." comment). Shame I have never had the chance to interview you, would be amusing you see you sit some of the programming tests I have had to devise and administer over the years.
As for "Working for someone else without getting paid." In terms of reporting a bug.
I assume from other comments you work involves OSS systems in some way, so OSS existence in effect helps to pay you.
Lets assume you work for a company, say you do not report a bug you find... say that letter a nasty exploit comes out, using that bug, and causes lots of damage (not to your system obv. but to others worldwide). Reputation of that particular bit of OSS plummets. Your company CEO, despite the fact you ensured his system was fine, decides to bring in a different product, for arguments sake not OSS..., your job goes.
So end result is lost job, overall reputation of OSS software damaged to some extent, great result for a bit of arrogance.
A key thing is the attitude of people once you report a problem; OSS development people will (generally) be glad of your help in spotting a problem, after all it is about community involvement, just because someone is not involved in day to day coding does not stop them contributing by code audit, testing the code, documenting the software etc. A bug report is not a criticism, its an aid to improving the software.
The response for "commercial" / "closed" software is likely (not guaranteed) to be slightly different - more bureaucracy, coders might not even be told of the bug or not be allowed to investigate it
Maybe you should read your comment and see how arrogant it came over. It exuded the sort of "I'm all right Jack" approach. By your reasoning its an "oh shucks" thing that lots of people died in New Orleans because they were too poor to own their own transport and so could not evacuate. Remember life is not just about you, its about people working together, things might seem to be OK for a while with a selfish tack, but sooner or later generosity to your fellow man is needed. Regard placing a OSS bug report as just one minor little selfless act you can do. Its not a big life saving thing, but its all part of doing the right thing.
--
Dave
Generated by SlashdotRndSig via GreaseMonkey
--
Cheers Dave
Generated by SlashdotRndSig via GreaseMonkey
It seems to me that anyone using any kind of computer system should have fallback contingency plans. If the application that you are using is suddenly discovered to have a fatal security flaw then this is no different from any other kind of failure - stop using the product.
Its no more acceptable to continue using software with a known vulnerability than it would be to carry on driving your car if you were informed that the brakes could fail at any moment without warning.
An immediate consequence of this would be than manufacturers would very quickly learn to make products that are maintainable enough that they can be fixed (or at least made safe) in a very short period of time. If a security flaw required 12 months to fix because it takes that long to test the product, then you have chosen that product unwisely - modular design and maintainability are important features.
A smart software designer will know that there could be a vulnerability and will design their software so that at least key parts can be enabled/disabled etc so that any vulnerability can be mitigated without total loss of functionality for the customer - like providing a mechanical lock as backup for an electronic car entry system - but with a way of disabling the electronic system if a flaw was found.
Full disclosure will lead eventually to better products.
This whole issue is a duck and cover move by software vendors. They wish to avoid their responsibility to create secure software by blaming those who reveal it doesn't work.
It's the Emperor's New Clothes in software, trying to fix the blame on the guy who points out you don't have any security, instead the guys who sold you the insecure software. Researchers have no moral or fiduciary responsbility to keep flaws in software confidential. The only benefit of keeping these flaws confidential is to the company that produced the software and to an industry where software security is frequently an afterthought.
It is not the responsibility of a researcher to keep his findings secret, it is merely polite to inform the software's owner in advance of public disclosure so they can prepare their response. I would suggest that 5 business days is good rule of thumb for minimum advance notice, this should be long enough for the company to prepare a response to the problem.
Fanatically anti-fanatical
as soon as the security hole is found. Otherwise people will continue to use something that is dangerous to them and possibly others.
Only by promptly informing the public can we be assured that no one will use software with a security hole in it. It also gets more people working on the task of patching the problem.
Hiding this information just hurts all of the users.
It implies no such thing. It's a perfectly legitimate way of expressing precision. Everyone wants "100%", but what does that mean? 100% could be someone thinking 95% was acceptable, but they're just rounding up to the nearest 5%. When you're dealing with actual statistics, fixing bugs, and intending to produce as near-perfect a product as possible, you deal in terms such as this.
It would have probably been clearer for some readers for me to say 99.9%, as you suggest. I apologize.
I don't appreciate the name-calling. Please grow up.
The idea has nothing ot to with criminalizing the innnocent (or the guilty, for that matter).
You're confusing criminal and civil law. A class action lawsuit can only result in an award of money, not prison or a fine. The worst thing that can happen to Joe Blow is bankruptcy (and a ruined credit rating). Obivously that's a huge problem if liability extends to open source (which is very unlikely, as other posters have explained), but it's not prison.
If he's offering a box set next to a 65 hours/week job, he's a fucking idiot and deserves all he gets.
First of all they should stop calling the mistakes"bugs". There are not "bugs" there, these are mistakes.
Actually at one there were bugs. I don't recall the year, sometime in the '50s if I recall right, but a piece of hardware developed problems. Nobody could figure it out until the hardware was opened up and techs found a real live, er dead, bug had caused a shortcircuit. After that saying there was a "bug" caught on whenever there was a problem.
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.
And it would cause many who program on their own or volunteer on FOSS projects to stop because of being concerned about being sued. It could very well also drive businesses out of business. Then again maybe if the US shut down NASA after the Apollo 13 accident, we wouldn't be where we are. If people aren't willing to take risk maybe they should find a cave somewhere. I do agree with disclosure though. Give people the info and let them make a choice.
FalconShould there be a Law?
For our machines with sensitive data, security is indeed more important than uptime, and, I really would prefer the machine shut down instead of staying up with a known vulnerability