What is Responsible Disclosure for Security Flaws? 235
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 (Score:5, Insightful)
Not necessarily (Score:5, Insightful)
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.
Re:Not necessarily (Score:4, Insightful)
What is the difference whether a security issue is "known...in secret" rather than simply "unknown"?
The difference is whether you know about it. After all, these are the only issues you can disclose.
Re:The cost of secrecy (Score:3)
Re:The cost of secrecy (Score:5, Insightful)
Response as in "confirming a bug report"?
What do you base your "reasonable" upon?
Are you aware that QA alone sometimes takes weeks?
I would prefer to keep the system exposed (in a controlled environment) to installing an non-QA-ed hack on my production servers.
Re:The cost of secrecy (Score:3, Insightful)
The ONLY people that have an advantage or early disclosure is Security folks, Sys Admins, and other IT people that care.
Re:The cost of secrecy (Score:2, Insightful)
And hackers, writers of viruses, and other such people. If the information is now public but the populace doesn't know/care, it's that much easier to exploit the security problem.
Re:The cost of secrecy (Score:2, Insightful)
Re:The cost of secrecy (Score:5, Insightful)
The issue is 'what is a reasonable timeframe'. Someone said 3 months, someone else said 1 week, and someone said it can take a year. As we all know, 'reasonable' is a subjective term.
I think 1 week is not sufficient. I work in a small software company and I deal with large companies. A large company can't issue a memo in 1 week, it can't get from the department where you reported it to the department that needs to fix it in a week (notify development, support, QA, and 'shipping/distribution' managers and get an impact statement).
As to the one year to fix it estimate, that seems very unreasonable, especially at Internet time speeds. The 'dark side' will be well versed in the bug well before that time has passed.
Is it 1 month, 3 months, 6 months, or 9 months? It probably depends on where the bug is located. We develop a small niche market piece of middleware. A 'full QA' run (specifically test new function, regression test all other functions) can take a couple weeks even using automated test suites (runs on 10+ platforms, several hundred tests per platform, some testing is single threaded due to 'expensive hardware' resource issues, some test have to be manual). Packaging issues across 10 platforms with doco can add a couple more weeks. All assuming we know the exact coding bug and do not have to analyse the reported problem.
So if a specific coding bug is reported in a core secton of the product, it can take a couple weeks of QA, plus Dev time, plus packaging, plus documentation, plus
Consequently, I'd guess 1 month is too short as well. I'd posit that a couple of months (3?) from the time the coding level fix it identified is probably a reasonable startng point. Given some reports I've received it can take from minutes to a lifetime to narrow the reported issue to a coding level fix.
Re:The cost of secrecy (Score:2)
Re:The cost of secrecy (Score:2)
Unless, of course, the software publisher does not take steps to address the security flaw, and an exploit is developed.
Sure, we may want to know the risk we are taking by using the unpatched software, but if the software is critical to the users' operations? Better to lessen the chance of an exploit.
At any rate, if you're using an irresponsible software firm for critical software, that's your own problem.
I do agree with your post in en
3rd party verification ... (Score:2)
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.
Re:The cost of secrecy (Score:3, Interesting)
I disagree to an extent. There are a couple reasons.
First, spreading a virus or other malicious code would probably be easier than patching the problem, at least most of the time. This means that exploits for a vulnerability would be be out before fixes for them.
I'd prefer the uncertainty that hackers may or may not have found a vulnerability above the certainty that they can find it, even at the cost of being unaware of the vulnerability
Re:The cost of secrecy (Score:2)
Should we make the same argument about driving or public health? When you use a networked computer, your actions or inactions effect the rest of the community just as much as your driving habits and efforts to contain communicable diseases.
The bottom line is that the hardware is yours. Any software you put on it that you don't author yourself is from a vendor. Microsoft has no responsibility for the health and well-being o
Re:The cost of secrecy (Score:4, Interesting)
First of all they should stop calling the mistakes"bugs". There are not "bugs" there, these are mistakes. If work for Ford and I am responsible for the carburators, I screw up and the QA never catches it and then people's cars are blowing up, it would not be called a "bug" as if something just crawled in there without anybody's fault, it would be _my_ mistake, a personal responsability.
The software companies are churning code to get it out of the door without adequate testing, it is their fault. If someone exploits it, it both software makers fault and the exploiter's. The company should restitute the costs associated with the loss. Hopefully, that would promote a culture of responsability, and software engineering would be taken more serously, just like mechanical, electrical or nuclear engineering is.
Chances are that if there is immediate disclosure, the users will have a chance to stop using the product until a patch is available. Every day until the patch is issued they should just bill the software company. That would be a great incentive to test well, code carefully and fix the problems faster.
Re:The cost of secrecy (Score:4, Insightful)
Chances are that a) no one will stop using the unpatched software because they can't afford to or they don't care to be informed of it (how many places were pwnt by worms that had known patches months in advance?)
b) No one will indemnify their code because it wouldn't be cost effective to do so and it wouldn't stop the issue.
It would be a *great* incentive but the cost of software would go up and either people would buy software that was less money (not as well coded) and put the others out of business or they would just continue on the old path.
Wishful thinking but it isn't going to happen.
Re:The cost of secrecy (Score:3, Insightful)
Say the keypad entry for all GM's had a flaw where if you pressed a certain sequence of keys, you can get into any GM vehicle that has keyless entry.
You go to GM and tell them they need a recall. They tell you they need to get with their suppliers, have them redo their software or hardware logic (after months of the engineers pointing the finger), or el
Re:The cost of secrecy (Score:3, Insightful)
The exploit grows in popularity in the darker parts of society, and GM cars around the country are now being broken into becuase you thought you were doing society a "favor".
But you ARE doing society a favour --- people will know next time that they should not buy GM cars because GM doesn't care enough to produce cars without such problems or to fix the problems in time! GM doesn't have a 'right' to retain its market share, and certainly not if it is culpably releasing and selling known defective cars. No
Take this to the extremes (Score:3, Interesting)
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..
Re:Take this to the extremes (Score:3, Insightful)
Some years ago, I heard an interesting interview on the radio with a fellow who was an ex-burglar. He had written a book explaining locks and how to test them for ease of picking. He also named a bunch of brands that were inherently weak. His argument for publishing all this was the obvious one: The pro criminals know this, or have ways of learning it. Don't you want to know whether your own locks are any good? And
Re:Best Security: 1st Amendment (Score:4, Insightful)
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.
Re:Best Security: 1st Amendment (Score:2)
Re:Best Security: 1st Amendment (Score:4, Insightful)
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....
Re:Best Security: 1st Amendment (Score:2)
Re:Best Security: 1st Amendment (Score:3, Insightful)
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
Re:Best Security: 1st Amendment (Score:3, Interesting)
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
"Responsible Disclosure" is a lie (Score:5, Insightful)
"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.
Re:"Responsible Disclosure" is a lie (Score:5, Insightful)
And to prepare legal proceedings against those that do end up disclosing the holes against the wishes of the companies trying to patch them (here [zdnet.co.uk]).
immediate disclosure is based on false premises (Score:2)
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 pos
Re:immediate disclosure is based on false premises (Score:4, Insightful)
Good point. From now on, I'm only going to allow those blackhats that don't know of the vulnerability to access my services.
And there's no evidence that any of them know of the vulnerability before the flaw is revealed.
You have a narrow view of reality. How can you know that no one knows of something before it's officially revealed?
The risk that they might know of it is what drives it.
While I'm on the fence as to which I support ( full disclosure or informed disclosure ), your arguments are flawed, and I had to point that out.
Re:immediate disclosure is based on false premises (Score:2)
Security is about reducing risk to an acceptable level, you can never eliminate it entirely. Believe it or not you are better off with only some blackhats knowing about your vulnerability than all of them.
Re:immediate disclosure is based on false premises (Score:2)
Not that I agree with this statement, but you only paint half the picture. Your statement implies trust in corporations to patch the vuln in a timely matter. The longer the system remains unpatched, the greater the risk to your systems.
Again, not that I fully agree with one side or another, but I feel a decent comprimise would be in order. The default policy would be to do full disclosure, but
Re:immediate disclosure is based on false premises (Score:2)
Re:immediate disclosure is based on false premises (Score:2)
And it's safer still to have the vulnerability fixed in a week instead of a month. Or 2. Or 6.
Re:"Responsible Disclosure" is a lie (Score:5, Insightful)
I'd argue that giving the software company a heads up to find a fix would be more responsible than immediate disclosure. There is no fixed amount of time either. If the company is unresponsive, wait as long as you feel appropriate and go public. If the company responds and appears to be making reasonable efforts to fix it, give them time. The public isn't going to fix the problem, so blabbing to them isn't going to help. Blabbing to them that the company has known for X months and isn't doing anything will help the public form an opinion about the company and move away from their products.
Re:"Responsible Disclosure" is a lie (Score:2)
That pretty well sums up my view. As long as the company is sincerely working on it, give them space. Some holes are obviously going to be harder to patch than others, so n
Re:"Responsible Disclosure" is a lie (Score:2)
However, if $company['foo'] is not taking adequate measures to fix the problem (which should usually be started|completed ASAP), then the security firm owes it
Re:"Responsible Disclosure" is a lie (Score:2)
I'm basically in favor of the approach of letting the vendor know, and
Re:"Responsible Disclosure" is a lie (Score:2, Insightful)
I agree that a and b are true, but that doesn't mean there is no such thing as responsible disclosure.
For example: it is irresponsible to release information about a security hole into the wild without informing the softwar
bull (Score:3, Insightful)
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 oth
Re:"Responsible Disclosure" is a lie (Score:2)
Keep in mind, all this "they knew it was a problem and did nothing" about the Levees in NOLA, is going to be rehashed with the borders, i.e. when something bad (terrorits, bird flu, whatever) comes over in an illegal immigrant, you are going to hear about how we knew the risks and no one did anything.
We are a reactive, not a pr
Wrong (Score:2)
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
I did it! (Score:2, Funny)
The question should be... (Score:4, Interesting)
Someone tells you that you have a security hole; you fix it - A.S.A.P!!
Re:The question should be... (Score:2)
Re:The question should be... (Score:2)
Your vendor should test it fully, though I appreciate no-one trusts their vendor that well.
Lets say I get a patch. I have to be 100% certain that this patch will not adversely affect the functionality of my system. Plus, I have to find an appropriate time to take it down - remember, this is a mission critica
easy: immediate disclosure with technical details (Score:5, Insightful)
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?
Re:easy: immediate disclosure with technical detai (Score:2)
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
Re:easy: immediate disclosure with technical detai (Score:2)
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
Thorny Dilemma (Score:3, Interesting)
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
Re:Thorny Dilemma (Score:2)
If software is free, no worries right? Got what you paid for... user assumes responsibility.
If software is a service or a product, there had better be backing to keep it supported against bugs. It's what people are paying for, if not on paper then in their minds. Peo
Wait as long as it takes (Score:2)
Re:Wait as long as it takes (Score:4, Insightful)
Re:Wait as long as it takes (Score:2)
Users who need the program/service because it's running their website or database server or whatever can't turn it off, and will probably already have it firewalled as far as possible without making it unusable. Users who don't need it should have disabled it anyway. And, unfortunately, a) crackers have
Tact (Score:5, Interesting)
An example of a tactful way first report it to the software developers and see if there is a patch. If not then get a little more forceful and release to the public that there is a flaw in a feature on this product and it seems to effect this range of people.
An example of a tactless method is to make a root kit that takes advantage of that flaw. Or tell the general public how to reproduce it.
You will need to remember what you say publicly will be used by people who will do good things about it and bad things about with it. So if you give them enough information to say block a port or temporarily turn off a feature vs. giving giving the bad guy a way in while the person will need to figure out what you did in your root kit then find that is the problem.
Be mindful when you report the flaw to the software company as well. You are telling them that they have an ugly baby and most people don't want to hear that. Try to be friendly with them but stern on the severity on the flaw. When it comes to reporting flaws you are no longer dealing with computers but with people and if you piss them off to much they will be less then helpful.
Re:Tact (Score:4, Interesting)
In the latter case, the only course of action (not due to spite mind you, though it felt good) was to release a usable exploit. The creator of said software had no intentions of ever fixing it. They had every intention of belittling anyone who brought such things to their attention. For me, the only way I would see this work, is if all of a sudden, the world was afraid to use software Y because a simple script kiddie could comprimise them.
Re:Tact (Score:2)
That is funny, i had this idea that somehow i was called freedom of speech.
Silly me.
Re:Tact (Score:2)
Now, those who "need to know" will vary according to the situation, the time since discovery, etc. I don't see it as a static thing. It is also affected by who else knows. Just because someone doesn't know about the flaw does not mean they're immune to the effects. Thus, anyo
Plain and simple (Score:5, Insightful)
Common Sense (Score:4, Insightful)
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.
why are the rules different? (Score:3, Interesting)
"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.
Re:why are the rules different? (Score:3, Insightful)
I'm honestly curious as to how the rules got changed for software.
I suggest asking Bill Gates. He was the pioneer for the EULA and software company not being responsible for anything.
I'm not trolling, Microsoft was the trail blazer in the legalease surrounding software today.
Re:why are the rules different? (Score:2)
Article Title (Score:2)
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 co
Risk to the public (Score:2)
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 allow
Re:Risk to the public (Score:2)
>
> Full disclosure increases risk. Malicious people who would not have known about such
> vulnerabilities often learn of them through full disclosure.
Debatable. Before accepting this, I'd want to see them numbers. Let's face it, even a year -after- patches are released, many people are getting hit. There are too many variables in this for me to accept any answer without seeing some real analysis.
And that kind of analysis is a job of wor
Rain Forest Puppy RFPolicy document (Score:2, Interesting)
http://wiretrip.net/rfp/policy.html [wiretrip.net]
Well thought document, written with input from big names in the computer security scene.
I don't know about you... (Score:3, Funny)
Why not... (Score:2)
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:
Responsible to whom? (Score:5, Insightful)
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.
Here's a question (Score:2)
- 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
Re:Responsible to whom? (Score:2)
I have seen few Windows XP machines that really updates themselves automatically. On almost every time i have to turn it on manually and then again a bit later on.
Lets Talk About What It's Not (Score:2, Interesting)
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 [wired.com].
-----------
WN: So ISS knew the seriousness of the bug.
Lynn: Yes, they did. In fact, at one point
Been there, done that (Score:5, Funny)
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!!!
blame shifting (Score:5, Interesting)
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.
It takes time ... (Score:2, Insightful)
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 - identifyin
Full Disclosure, OpenBSD (Score:2)
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."
That's because you're a defective person. (Score:5, Insightful)
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".
Re:That's because you're a defective person. (Score:2)
What little negative feedback that these people get is good for all of us -- the zombies are a threat to us all, if only due to a DDOS.
Yeah, I'm happy that Mac users have to reboot and suffer their share of problems. They've chosen to hand their security over to Apple. It is important that they suffer some consequences now and then.
I guess I wouldn't be such a crab if running a BSD box wasn't so irritating.
One group to rule them all (Score:2)
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 stre
Issues With Disclosure (Score:2)
-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 pre
Security researchers problematic bunch? (Score:2)
Security researchers problematic bunch? [zdnet.com.au]
Solution to the problem (Score:3, Funny)
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.
Re:Solution to the problem (Score:2)
MSFT the Whipping Boy Again ... (Score:2, Insightful)
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 o
It is all about priorities (Score:3, Interesting)
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.
Re:It is all about priorities (Score:2)
I have a slightly different take on it. As a user, whether or not the vendor has released a patch there are still things I can do to mitigate my own risk from the vulnerability. I can, for example, restrict or block access to the vulnerable services, or change from the vulnerable software to some other software that's not vulnerable. But I can only do that if I know the problem exists. As a user I don't particularly like a vendor deciding that their QA resources are more valuable than my network and systems
Re:It is all about priorities (Score:2)
The problem I have with full, immediate disclosure is
Not an easy solution... (Score:2)
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.
Openswan project directly affected (Score:5, Interesting)
The Openswan project [openswan.org] 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 ?
Re:Openswan project directly affected (Score:5, Insightful)
Refuse to sign the NDA. Then make a public announcement: "$AGENCY has notified us that a possible vulnerability exists, however they won't tell us what the vulnerability is unless we sign an NDA. Comitting a patch to fix the problem to CVS or releasing fixed code before they allow it would violate the NDA, and we aren't willing to agree to deliberately not fix a security bug.". Let the resulting PR headache be $AGENCY's headache.
Security Auditing in Software (Score:2)
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
Security problems in the hidden (Score:2)
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.
Timely disclosure is a must (Score:5, Informative)
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.
I Call Bullshit (Score:2)
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 ex
morally responsible user? (Score:2)
Extreme cases (Score:2)
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?
Re:hypothetical situation (Score:2)
Now, replace diebold with Apple, the ATM machine with FairPlay (the money being copyrighted goods), and the researcher with DVD [Jon].
You're comparing Situation A, which involves random ATM users stealing cash (in limited number) from banks, with Situation B, which involves making a copy of an audio file (which you have previously paid for via iTunes, and which does not decrease the number of audio files in any way) so that you can listen to it on an alternate device. Are you really saying that these tw
Re:Two types of disclosure (Score:2)
2) Disclosure of an exploit for a vulnerability... Type 2 disclosures should be shunned by everyone. These present an immediate hazard to end users and provide no conceivable benefit to anyone
I disagree that this second type of disclosure is never warranted, but I believe there need to be some serious mitigating circumstances. For example, if your own network or networks critical to the "good of the people" (think social security database) are being attacked or compromised using an uncommon and largel
Gah. (Score:2)