Slashdot Mirror
Hackers Disagree On How, When To Disclose Bugs
darkreadingman writes to mention a post to the Dark Reading site on the debate over bug disclosure. The Month of Apple Bugs (and recent similar efforts) is drawing a lot of frustration from security researchers. Though the idea is to get these issues out into the open, commentators seem to feel that in the long run these projects are doing more bad than good. From the article: "'I've never found it to be a good thing to release bugs or exploits without giving a vendor a chance to patch it and do the right thing,' says Marc Maiffret, CTO of eEye Security Research, a former script kiddie who co-founded the security firm. 'There are rare exceptions where if a vendor is completely lacking any care for doing the right thing that you might need to release a bug without a patch -- to make the vendor pay attention and do something.'"
What we need is a government office that handles this sort of thing, because National Security can depend on bug fixes.
There needs to be a law against releasing exploits without giving the comapny time to react to the find.
Perhaps there should be a software developers association that a company can join that handles oversight on this issue. Any "hackers" that find a critical bug with a piece of software could bring it to the association's attention, and there could be sanctions if the developer refuses to fix it.
Comment removed based on user account deletion
It's good to see that opinion seems to be shifting on the matter.
A few years ago when Microsoft started pressing for "responsible disclosure", they were pretty much mocked and ridiculed by everybody.
I'd like to think that there is now some real discourse on the effectiveness and responsibility of full disclosure vs responsible disclosure, and that security researchers are choosing responsibile disclosure more often.
I'd prefer to think of things that way then to cynically surmise that this is simply a case of "when it's an MS bug, let's roast them with a 0-day disclosure, but if its anyone else, let's give them a fair shake at fixing it"
My opinions are my own, and do not necessarily represent those of my employer.
What do we want? PATCHES! ...
When do we want them? NOW!
If a vendor demonstrates that given an exploit of a certain importance, they'll patch within a reasonable amount of time (sooner than some other hacker will figure it out)- then by all means tell them first- but otherwise, force them to react quickly.
Comment removed based on user account deletion
I still find it hard to believe that hackers on Slashdot would be so appalled regarding the release of bugs to the public as soon as they are found.
Once upon a time, software vendors would emblazon their products with the names of those who created their software. But these days, all the names are hidden from public view, reminding all that it is the corporate king, not a programmer, that creates software.
So in the spirit of openness and the spirit of fame and fortune, I say "congrats" to those who are willing to put their name, reputation, or even morals, on the line to discover and announce these bugs as soon as they are discovered. In the end, it will make the world a safer place.
.... at news.com:
a mpaigns/2100-1002_3-6147026.html?tag=nefd.lede
http://news.com.com/The+good+and+the+bad+of+bug+c
This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
March 1996 to April 1998: I was a script kiddie in my mom's basement.
/not that there is anything wrong with that...
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
If these bugs aren't publicly disclosed many software vendors see no reason to fix them. The reason for this is each time you fix a bug the product has to go back through a full QA cycle - which can cost lots of money.
One problem in this debate is that often, either side will make it seem like an all-or-nothing proposition; that it's either "full disclosure on day one" (or in this case, "day 0" ;-), or it's feebly report to the vendor and wait helplessly while the faceless vendor takes months to respond, if it even responds at all.
There actually is a middle ground.
Some say, "Hey, these vulnerabilities exist whether they're reported or disclosed or not," just as MOAB says in its FAQ. But the problem is that they overlook the practical side. Sure, the vulnerabilities, and maybe even working exploits, exist, but as long as they're hoarded (and not used) by very small and tight-knit groups of people, they're not getting actively exploited in the wild across massive userbases. Could high value 0day exploits perhaps be used for isolated penetration? Sure. But could they be used (for any period of time) for a mass-spread worm or other malware? Nope. It'd be hours before security firms and/or vendors identified the issue.
So when you choose to disclose previously undocumented issues before giving the vendor any chance to respond, which some claim they're doing to improve security, there is a greater chance of exploit across a much wider base of users, which can have a much wider and catastrophic impact. Some say that as a sysadmin, they'd want to know about such vulnerabilities so that they can protect and mitigate themselves. But other than for high value targets and corporate or government espionage - which can perhaps have their own channels for "earlier" disclosure when identified by entities like US-CERT or Information Assurance agencies - I don't see how people can reasonably expect to be targeted by extremely valuable and as-yet-undocumented vulnerabilities. It's a point of pride - and sometimes money - to sit on such vulnerabilities.
The bottom line is that the vendor should always be informed in advance, if there is any real concern about security on the platform, and not just ego stroking or slapping down "fanbois". How long in advance and how long a vendor should be waited on is somewhat subjective, of course. Also, no one's saying that an "independent" "security researcher" is beholden to a corporate interest. But then they shouldn't operate under the guise of responsibility or the feigned notion of wanting to "improve security", when some persons' mechanisms for disclosure are nothing more than PR attempts, or another notch in the bedpost (hmm, or probably NOT a notch in the bedpost...)
Now, in breaking news, polarizing issues cause people to disagree! Film at 11:00!
The problem with setting any reasonably lengthy period of time is that it results in that much more infection and use. Basically, this grants any purchaser of a 0 day exploit roughly a 2 month window of opportunity to use their new found investment.
Where as there may not be a patch to solve the problem, but perhaps there is a significant work around that could avoid some trouble.
This is exactly why it is difficult to assign a window of disclosure to such issues. Not too terribly long ago, some of the larger firms managed to get together and settle on a 30 day notice.
Also, you might also remember that a little company called Cisco was sitting on a vulnerability for quite a while until someone when psychotic over the deal.
In the grand scheme of things it comes down to protecting your image. It almost seems like the policy on vehicle recalls. Unless X number of issues arise... just don't deal with it. However, if it becomes substantially used or finds the public eye... it suddenly becomes a much larger problem.
Honestly, an arbitrary date is rather inflexible and a system that takes in effect the impact of the bug needs to be used. Pump out tons of crap software? That isn't exactly the problem of the common man, but rather the problem of the organization's software development model.
Organizations and individual people lose time and money to support these industry bug shields. Again, a case by case determination depending upon the level of potential harm.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
If the fix is as easy as closing ports 135, 137, 138, 139 and 445 in the firewall, then you can disclose it immediately...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
I think that "responsible disclosure" is fine for companies that:
;)
1) Make real attempts to release secure software, rather than just ship shoddy software as fast as they can onto the unsuspecting public.
2) Have a serious method for responding to issues quickly and effectively when they are found outside the company. This really just means good customer support combined with a good method of patching shipped code safely and effectively.
3) Treat security researchers as friends who help improve their products.
For other companies whose arrogance and lack of understanding are obvious ("Unbreakable" anyone?), I think that full disclosure is the most responsible action by a security researcher. These companies are doing the equivalent of shipping cars without airbags in the modern world, and then in many cases lying about it. That behavior needs to be "shocked" out of them, and for that reason, I think "30 bugs in 30 days" kinds of exercises are good for the software community overall.
In other words, "The beatings will continue until morale improves."
Giving the vendor a few weeks to create a patch before releasing an exploit is a polite thing to do for the vendor's sake, but what about the users of the vulnerable software? Hiding potential threats from them keeps them from protecting themselves. Even without a fix, you can apply a workaround or if you need serious security, even replace the buggy product. I think that researchers who find security bugs should report the fact that a vulnerability exists in a given software product immediately. They can wait to release working exploits if they want to be nice to the vendor. Moreover, any legal restriction on releasing exploit code would be totally unethical. Code, even malicious code, is a form of free expression.
------ Take away the right to say fuck and you take away the right to say fuck the government.
Hackers are not under any obligation to disclose anything. I'm not aware of any law that either forces them to disclose a vulnerability that they have discovered, or any due process that must be followed to do so. I'm also not aware that writing or distributing proof-of-concept code is illegal. Judging by the number of large software vendors either in court (IBM, SCO) or deliberately misinterpreting existing legal documentation (Microsoft and Novell attack the GPL), the law is clearly the only deciding factor in how business will be done in the IT industry.
Therefore, throw your morals and principals out the window. This is laissez-faire economics at it's best. Mud-slinging, sabotage, legal wrangling, death threats and more await as we determine just who has the best software. If these vendors are truly interested in some good-faith reporting from the people who are discovering the vulnerabilities, maybe a show of good faith on their part might be nice. There's absolutely no incentive to do anything in a reasonable or "nice" way, when dragging a hated vendor's name through the mud is both legal and cool.
There's a few things I can think of that would improve matters and reach a common ground where truly malicious software is written only by a few bad apples:
Just to be perfectly clear: I am condoning the MOAB and any other MOxB. I've used too much bad software and seen too many vendors be held utterly unaccountable for their pre-meditated actions against the consumer. Lobby groups funded by these large vendors continue to erode consumer rights. If this is not how business is to be done, perhaps the industry leaders should set a better example.
mandelbr0t"Please describe the scientific nature of the 'whammy'" - Agent Scully
... which Maria Sharipova poster is the coolest. ... which STTNG uniform best hides Romulan blood stains. ... baked or fried Cheetos. ... best way to get your parents out of the house for the weekend.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
>>"I've never found it to be..."
Nothing more than "I've never thought it was..."
How ever the hell I want. When ever the hell I want.
That's how and when.
As soon as the patch is released, the crackers will be checking the files replaced and the differences in those files.
They can usually get and exploit fielded within 24 hours or less.
The best you can do is to take steps to minimize the threat and log any activity so you can see if you've been cracked. Running snort can tell you if any traffic is suspicious.
But you should be doing that anyway.
In one of my previous posts, I have already talked about this.
Companies have no other interest or goal other than to make money. Fundamentals people, fundamentals! If you think, for one second that an idea from any company not resulting in immediate profit is correct, you are a fool. They cut corners, discriminate based off of accredited and formal education rather than will and raw expertise and experience, they implement managment schemes that do more harm than good for the sake of book keeping for VCs and shareholder confidence. They have to make every judgment off of a cost analysis report. And what few people understand is, if it's cheaper to continue in the same path, they will even if people are dieing (car manufacturers) or getting screwed (Microsoft software unreliability).
I can't believe this debate is taken seriously! The Companies want this precedent, because it's cheaper to ignore most exploits than to actually have to hire someone that can do something to better the software. Companies want this because it adds another variable (in their favor) to the cost analysis of fixing a problem... it gives them choice. And as we all know, from Companies' own assertions, that choice is bad and force is the only thing applicable. Companies don't give you much of a choice, why should you give them any? Open Source doesn't get a choice, why should their competitors (proprietary software). If Capitalism is the so-called "best", then it should be able to compete in the exact same fashion and prevail as other systems. So don't do this double standard crap of "Oh, if it's a company software, do 'X' if it's not, then do 'Y'; only because of a benevolent precedence suggesting you should give a Company a break while it's OK to lay hard and firm on some other ideology."
If a Company releases software that is buggy. The very instance you find an exploit, it should be released to the public with all that you have researched including example exploits. If the Open Source community can fix it quickly, then surely Microsoft or Adobe can too with their all-mighty Capitalist ideals and absolutely-necessary 'management'....
There is no precedence here. It is not a debate. You paid for the software, and if you don't get what you paid for (and some), then you should have absolutely NO qualms of sticking it back to the person who pawned it off to you. If they are so great, then let them prove it. But they aren't, and that's why they are coming up with all these little social tricks trying to get people to make an exception to further propogate the illusion that proprietary software is "good" the "best money can buy" or what ever.
You paid for the software. It's yours. You got screwed. Let people know! If you got screwed at the used-car lot, you'd let your friends know the details... you'd even feel socially obligated to do so. Software is NO different. You are socially obligated to blow the whistle for every little thing you find, and blow it till you're blue in the face; you paid for it, and you didn't get what you expected. It is NOT illegal to blow the whistle on crappy products you end up paying for. In fact, for some products it's a federal offense to pawn off crap to the consumer (think Lemon Laws in the United States). If you really want to get technical, then there already is legal precedent set in this regard because it's illegal to sell a car that is reasonably too problematic in the United States. Maybe we should make it illegal for software Companies to release crappy and overly buggy software too!
If you find an exploit. As soon as you can write up a concise report, sample code et al. and hit the "Send" button. DO IT!
eEye, eEye....oh!
With a hack, hack here and a hack, hack there. Here a hack, there a hack, everywhere. . .
Oh, wait, that's "My Friend Jason."
Nevermind.
KFG
Unless you are dealing with a company with one developer, they should be able to put people on the problem and find a solution ASAP. I understand it takes time to fix problems but nothing ticks me off more than when people drag their feet finding a resolution because they don't feel it is a high priority.
Full disclosure debate.
Hackers have no legal obligation to do much of anything, but neither is basic human decency (eg. cleaning up after yourself if you make a mess in the company breakroom) a legal obligation. Just because what they're doing isn't illegal doesn't mean it's a good thing to do. Nor am I trying to argue that it *should* be illegal - it shouldn't. I'm just saying that giving them a pass just because they're not breaking the law.
Also, why give them a pass because they're MOxBing select vendors? Wouldn't it be better to reward better vendors with high marks for security consciousness and punish worse vendors? This choice based on PR seems like so much grandstanding.
I am the one true god. However, as an atheist, I don't believe in myself. I guess I have a self-esteem problem.
Companies have no other interest or goal other than to make money. Fundamentals people, fundamentals! If you think, for one second that an idea from any company not resulting in immediate profit is correct, you are a fool.
This stems from the simplistic notions that a lot of engineers have that companies are just like giant computers, programmed only to maximize money creation.
Over time, you will come to realize as I have that companies actually are composed of many PEOPLE. Companies do nothing by themselves.
Sure people within the company are, sometimes, trying to make the company money. But they also have external motives, emotions, and plain old human irrationality that feeds into choices made as well.
Generally the companies that do well are not trying to maximize profit, but generally are trying to help customers the most. That is, in the end, what leads to money - simply trying to lower expenses is not a long term path to wealth creation, and only works for so long - it cannot be sustained.
The more foolish fool is one who believes as you do - that all companies have simplistic goals, that are not at all influenced by human behaviour.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Folks, security holes are NOT a "given". All software does NOT have an endless stream of security holes. It's NOT impossible to create software without these ridiculous, high-school-student bugs like buffer overflows, off-by-one errors, and improper validation of input.
This is a very dangerous path we're on. I pay Apple, Microsoft, FreeBSD Foundation (yes I donate annually), whoever, with the reasonable assumption that they deliver SECURE SOFTWARE, and that they've made an effort to plug holes BEFORE the software is shipped.
I pay food companies for food that doesn't make me sick, and when it does, the food companies are PUNISHED. They don't thank me for the "bug report". I pay car companies for cars that don't crash under normal use
Some of these comments here on slashdot and other places like bugtraq are truly frustrating. Doesn't anyone recognize the SOURCE of the security holes?? The VENDOR? Point your fingers in the right place.
Mark? Buddy? They had the chance! They could've fixed the bug BEFORE SHIPPING! But they blew it!
Even the concept of bug-finder as "security researcher" is flawed.. these aren't bugs that are naturally occuring in nature, this is HUMAN ERROR!!
As far as I'm concerned you have three options when you discover a security hole:
1) do nothing
2) patch your copy for yourself and your clients, and keep quiet
3) report it as soon as possible to the public, and hope that the vendor learn a lesson
Personally, with open-source, and especially with my clients, I stick with option #2. I don't have the balls to do #3, but I'm thankful for those that do, even though I wish they didn't have to do that.
Vendors DO NOT DESERVE to have their hands held and their dicks sucked when it comes to FLAWS in their products. If you're a fellow programmer, don't let yourself believe that it's IMPOSSIBLE to write secure software and then just give up.
At this point, I'm 100% ready for legislation that punishes software security holes. But I fear the attitudes have shifted too much.. the only legislation we'll likely see is one that punishes BUG REPORTS. Does that make sense to anybody??
Seriously, sit down and imagine the end-result of "responsible disclosure" and the attitude that "all software has holes" and so on. Will this give you MORE secure software, or LESS? 20 years from now, what will security look like? Will software be simpler and more secure, or more complex and easier to hack? What has been the trend up to this point?
If anyone can think of a market-based solution, let's hear it.
..."hackers disagree".
If you don't, they may find away to get a court order to make it so you can't disclose instead of fixing it.
Or any of a number of dirty tactics.
Sorry, but even the briefest look at the history of corporate attitude indicates that they can not be trusted. This goes baco to corporation before America even existed, not just American Corporations. One reason Why I agree with Ben Franklin when he said that the constitution should ban corporations.
The Kruger Dunning explains most post on
Wow. Do you have any evidence whatsoever to back that claim up? Or did you just see it on IRC somewhere?
Back in reality, it is almost universally assumed that published exploit for which no patch exists will lead to much more damage than a published exploit for which a patch is widely available. In fact, it is so obvious (to almost everyone but you) that such a study has never even been performed.
The security community shuns researchers who publish exploits without allowing vendors a chance to patch. Security researchers who practice "full disclosure" instead of "responsible disclosure" are widely considered malicious and immoral.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Which leads to the suspicion that it's all not a technical but a public perception problem, hence a marketing issue. Which leads me to think we should disclose as early as possible to give the manufacturer some good spanking because after all, it's them who are responsible for the issue, not hackers, and not security folks.
How's that. Security organizations start keeping track of how long a given company X needs in average to provide a working fix for a problem. Let's start with 30 days. Then to give'em an incentive to progress on fix times, disclose half of the average days after notifying the company. This way, manufacturers can publicly demonstrate how serious they take their customers' security problems caused by their software, and how well their Q&A processes work. Next, publish lists of minimum, average, and maximum fix times together with the companies' names, and voilà, everybody knows what's going on in the market and who better not to buy from. Companies themselves can find a balance between being quicker (and more trustworthy but more costly in terms of Q&A) and being slower (and potentially losing sales, hopefully). That will show how well management processes work, not ISO9000 and other marketing-motivated bullsh*t.
Keeping track of and publishing the averages would be a governmental task in all countries that are totally free of bribery.
You get the idea...
open (SIG, "</dev/zero"); $sig = <SIG>; close SIG;
Your argument fails for the exact same reason you cited for mine.
Where do you get your data and how do you know an uncovered exploit is not being actively used.
YOU DON'T...
Exactly at what point did I say research materials must be placed immediately? I didn't did I? That wasn't a mistake as I wasn't advocating the release of exploitable vulnerabilities immediately.
You failed to read my post, you failed to interpret what little you did read and ultimately gave off a gunshot reaction to some thought you formed in your head. Maybe a little more reading next time before you troll eh?
I was advocating a sliding window based on the problem at hand. Severe holes are just that for a reason and if a problem is so gaping that it must be addressed in some fashion then perhaps two months is not the answer. We have seen unofficial patches from others and we have seen vulnerability work arounds from others then the official vendor.
In any event, please troll else where.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
I'm not sure I really advocate holding a proverbial gun to someones head. I'm just not much of an activist in that regard.
Maybe not a threat so much as a response rating? Surely tracking data on responsiveness would yield long term value in addressing these problems. Couple that data with the line item fixes and vulnerability time lines as well as threat values should show a negative or positive history with regards to quality assurances.
Honestly, I'm sure something like this has to exist already doesn't it? It would seem like a sensible enough idea anyway. I'm also not speaking from the perspective of when an issue becomes public to fix. I'm speaking of simply tracking the issue from notice, notification to patch.
It may not be the best avenue from the consumer stand point, but it would be a gentle start.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Oh and to start off on your whole mis-rant there...
It's common sense...
The longer a problem persists the worse it will become.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
if you know about a new vulnerability, vulnerability information for an existing vulnerability, an exploit for a known vulnerability (or a working PoC) - you hold the keys and decide what to do. there is no written or unwritten law that says you have to go to the vendor.
but going to vendor does have its benefits. for example, microsoft usually gives you a year access to MSDN if you disclose to them responsibly.
i have been a part of the disclosure process from all sides (black/gray/white, vendor/operator/programmer, administrator/user/manager) for a very long time (15+ years). talking to people post-disclosure is where i usually learn the most. many people that are new to the process of disclosure are quick to join sides or make hasty decisions. they often make very large mistakes by doing so.
MoXB is the new problem for disclosure. every year a new problem seems to crop up. in 2005, it was tippingpoint's zero-day initiative and similar programs that would pay for exploits. hdm had the "spirit" of honest and good full-disclosure when he started MoBB (and Microsoft repaid him in serious amounts of beers and respect, plus he may have received money or other resources from them). but MoKB and MoAB with LMH and KF are totally different.
let's step back a little and talk about vulnerability lifetime. a vulnerability is best handled by full-disclosure immediately following the discovery. full-disclosure in this way should always involve vulnerability information and should not include a working exploit or PoC. if a PoC is necessary to prove or explain the problem further (iow: the vulnerability information is not enough for most organized and technically savvy people to figure out the rest) - then it should be released as full-disclosure as well, but only after the original vulnerability information is documented and discussed. things to be discussed in this process include the accuracy level of the PoC (while still broken) to prove the concept - without the ability for those outside the level of relevancy (organized and technically savvy people) to use it as an exploit to steal your mom and dad's credit card numbers or similar. the discussion should also involve how the PoC will affect the world, i.e. levels of damage, costs to organizations, global effect, etc. if these outweigh a decision to not release a PoC - fine - don't release one... just release more vulnerability information until a patch arrives.
a patch doesn't "kill" a vulnerability (iow: end the vulnerability lifetime), but it is the first step to death. however, it can also be the first step to get a working exploit. this should also be taken into account when the vendor (or a third-party) goes to release a patch, how the patch should work, and how it should be distributed.
the only reason "responsible disclosure" exists is to allow this discussion to happen "with the experts" and to go for the patch/fix through legitimate, official channels. in my opinion, most of the experts of any given vulnerability information for any given vendor are almost completely outside of that vendor. no vendor (Microsoft, Cisco, Redhat) maintains the best people in the business. many of these people don't even work for a company at all, and many are also not even associated with any open-source projects. their review is more important than what is available inside the vendor. the vendors know this because they are always defaulting to the intelligence outside themselves - in their "community". debunking the expert-argument is easy, but the patch/fix argument remains one good reason to allow the vendor some time through the responsible disclosure process.
that is - until the vendor becomes greedy or wasteful, which always happens and this isn't going to change anytime soon - especially with companies like Microsoft, Oracle, and [more important and relevant today] web-companies. hence, projects like ZERT and Ilfak who are starting to supply third-party patches for vulnerabilities. now we have a situation where
If some institution loses your data to whomever..when do you want to be informed? Left up to the vendors, they would never tell you. California even had to pass a law mandating they tell you, because these profitable concerns just don't like exposure for forking up, even if it means your soc sec or cc info gets compromised. Don't you want to know soon as possible, and wouldn't you think it would be irresponsible of them if they failed to tell you? Now what about software vulns, if you are a user, maybe even paid serious cash for the "use" of the software? Do you want to know if the thing is vulnerable, at the soonest? So you can make a decision, keep using, sandbox it more, switch to application B-whatever? Or once again do you want that choice taken from you, because the nice company knows better than you and you don't have any right to your own info to make sure it stays secure? That's what we have now and it SUCKS.
I think the choice is clear out of all the sucky options-full disclosure as soon as possible. If one dood can find a vuln and report it, there might be several more who can find it and exploit it and not tell anyone about it. Giving the for-profit vendors *any* slack just leads to sloppy coding in the first place with security job #967 on their list of priorities (MS is the classic example) and an excuse for them to procrastinate on a fix. Yes, this is not a perfect solution, there are obvious failure points, but they are much less than the alternatives. Compromised data or the potential thereof is in the consumers "right to know ASAP" territory. The vendors cash your check, let them work for it. When I see an industry with just scads of billionaires with products with ZERO WARRANTIES I think the point is clear-they as a rule just don't give a crap about end users, because you hand them a check regardless, because of this mass successful brainwashing that for some reason software is "special". No it's not, it is a human endeavor. If your local muni water supply is tainted, do you want to know NOW, or next week when they get around to fixing it? If Acme Aeroplanes has a little problem with half their engines failing because of a bad production part, do you want to know NOW, or in a few months when they may or may not want to tell you about it?
Mandated or casual "everyone does it" vuln obfuscation has lead us to the place we are at now, still stuck on the daily huge bug or vuln de jour, because there simply hasn't been enough heat applied to the ones who insist their alleged products be covered by every IP and corporate scam, dodge and law-wiggle profit protection they think of, but OFFER NO WARRANTY for. Just the no warranty part negates, to me, any claims whatsoever they have on obfuscation of bug vulns.
Screw 'em.
They want patents, trademarks, copyrights, maximum profit PLUS the ability to stay in business without *any* warranty protection for the consumers, let them feel the heat same as any other product or business out there.
No more special deals for software companies, it is now a well established mature industry that doesn't need that level of protection, they can take the training wheels off now and enter the grown up world of adult responsibility for their "products". Go ahead and post the bugs, let the chips fall where they may and FORCE rapid evolution oin the software world to someplace better than what we have now. If 7/8ths of them go out of business because they can't hack it, pun intended, who cares in the grand scheme of things? Really, where's the beef?
The companies that can hack it will produce outstanding software, and isn't this what we want anyway? You bought any NEW DeSotos lately? Has it hurt the auto industry to have failures fail? They want globalism, outsourcing, maximum return on minimum investment and effort, fine, let them eat the results of lowest common denominator crapware with no warranties. Post the vulns!
He publicly announced that there was a flaw in the chip, and that it could lead to a root exploit, gave a few clues, and a movie of it in action, but nothing that explained how it worked, and didn't let anyone know except apple...
Then all of a sudden he went quiet, and stopped responding to all questions about the exploit... people believed it was because it was a hoax, however it appeared that apple gave him a court order to be quiet...
Months later and apple still hadn't patched the system, the guy reappeared touting his exploit again, only this time its for a intel chipset, altho the expoit method was the same, since it wasn't apples problem, he was freed from what was probably a restraining order
Anyway, sorry i can't give any real citations, but regardless the moral of the story is true,.. If your going to give them advanced warning, it means you can't do it anonymously, which means they can get a court injunction against you, and continue sitting on the exploit.
To avoid criticism; Say nothing, Do nothing, Be nothing.
Moves like publishing exploits immediately force companies to patch their software faster. Chances are that if the researcher knows about the exploit, someone else does who is already using it for nefarious purposes.
Not all conservatives are stupid,
but it is true that most stupid people are conservative.
- Hume
Actually, you are completely, categorically, and 100% wrong.
Apple did NOT give anyone any order, court, legal, threat, or otherwise, with anything having to do with the wireless issue.
In fact, your entire timeline, and nearly everything in your post, is completely wrong.
Brief summary:
- The exploit was shown at Black Hat and demoed on a MacBook with a third party wireless card first. Apple was NOT informed of the issue.
- The issue affected numerous 802.11 chipsets, drivers, and multiple operating systems, including Mac OS X, Windows, and Linux.
- He "went quiet" because the Washington Post unleased a firestorm of bad press against ONLY Apple. This issue affected basically every platform and was a serious, general 802.11 vulnerability, but the Washington Post story and nearly all press coverage, especially mainstream press coverage, made it appear to be only an Apple issue, and often made no reference to multiple other platforms being affected. This was extremely embarrassing for SecureWorks, which claimed to be a responsible enterprise security company, so they probably told him to STFU, since he was doing his presentations under their name. Apple DID NOT do anything to force or otherwise or prevent him from talking. If they did, it would be easily provable. And no, there aren't any "gag orders" or any other such things.
- He didn't "reappear" and "tout it for an Intel chipset" (???). He showed it at Black Hat, and demoed it on a MacBook (with a third party wireless card). There were no "restraining orders", and your order of events shows you have no clue what you're talking about.
- Apple was the FIRST commercial vendor to patch this issue (partly because of the huge amount of negative attention that all the stories that made it look like only an Apple issue created). Only Linux drivers were patched sooner.
The reason you can't give any citations is because you're totally wrong, and your entire premise is wrong. Not only that, you CAN give advance warning anonymously. Further, Apple doesn't threaten people who tell it about security vulnerabilities. In fact, it routinely credits people - including some who remain anonymous or operate under pseudonyms - in its technical documents about security updates. Every security update has numerous people credited for providing information about security issues. There is NO CASE where Apple has taken ANY court action, ever, against someone who has reported a security issue. None. I know you're thinking "but, but, but, some blog told me this" or "I think I read such and such somewhere." No. There has never been any case of that, at all. Apple HAS sued to keep its future products and confidential information secret, but has NEVER taken any action for people reporting or disclosing security issues, period.
So basically, your entire argument, while being wrong to begin with, is still shattered because Apple has never taken any such action, in this case, or any other. Responsible disclosure to the vendor is the way to go.
Here's what really happened, from a post I wrote up about this yesterday, actually:
At the Black Hat Briefings in Las Vegas, Jon "Johnny Cache" Ellch teamed up with former SecureWorks researcher David Maynor to warn of exploitable flaws in wireless device drivers. The presentation triggered an outburst from the Mac faithful and an ugly disclosure spat that still hasn't been fully resolved.
Um, yeah, because nearly all of the news coverage of the vulnerability didn't describe it as the general 802.11 vulnerability that it was, affecting multiple chipsets and drivers and multiple operating systems, including Windows, Mac OS X, and Linux; it described it, and indeed trumpeted it, as vulnerability that affected Apple MacBooks and Mac OS X, with most articles making at best a passing reference that it could affect other platforms, if they even said that. Stories ran under headlines like "MacBook hijacked in 30 seconds -- wirelessly", and made it appear to be exclusively an Apple problem.
Yes, I don't give evidence to back up my claim because it is... obvious. You made an outrageous claim that flies in the face of common sense and reason. No one would take such an unlikely claim seriously unless there was evidence to back it up.
Here's an example:
Which is going to cause more damage:
a) releasing a contagious pathogen into a population before a vaccine has been developed and distributed
b) releasing a contagious pathogen into a population after a vaccine has been developed and distributed
I don't need to provide evidence for b). It's self-evident. I would consider the possibility that a) is true only with strong evidence.
The pathogen is similar to the situation in discussion here. "public knowledge of a security vulnerability" is analogous to the distributed pathogen.
Even though it is possible that the pathogen exists somewhere, it obviously isn't doing much damage or else it would have been noticed. If you're going to start spreading it around to everyone, it's best to wait for the vaccine.
So yeah, I don't care what your intent was. The part of your message I quoted flies in the face of common sense, yet you state it confidently as if it were a fact.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Once again, you fail miserably. Your argument is only 'obvious' because you assume it is. But GP addressed that sufficiently.
Your metaphor is completely ridiculous. We are not talking about releasing a pathogen, but the information that a pathogen exists. What will do more damage?
a) releasing information about a contagious pathogen to the population so they can take measures to avoid being infected until a vaccine has been developed and distributed
b) keeping the information secret so that people go about their business thinking they are secure until a vaccine has been developed and distributed
The pathogen isn't the knowledge, it is the bug (or the fact that it can be/is exploited), and it has been noticed or the question wouldn't pose itself, would it?
But really I doubt you will understand think message either.
"Back in reality [...] I don't need to provide evidence. [...] So yeah, I don't care what your intent was."
Why not just say "I am just an idiot who confuses his little thought experiments for reality and don't care one bit about logical consistency or truth." I think that sums it up nicely...
Programmer: Some new code made by my company is executing on a server. A remote vulnerability is exploited. The server crashes and all of the data is lost. Now, should we push an emergency patch? Take the number of servers using the software in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of Q&A, we don't do one.
Woman: Are there a lot of these kinds of accidents?
Programmer: Like you wouldn't believe.
Woman: Which software company do you work for?
Programmer: A major one.
"Beware of he who would deny you access to information, for in his heart he dreams himself your master."
The problem is your analogy is not exactly correct (which is the usual problem with analogies.
The difference between full disclosure and just informing the companies would be a lot closer to just telling the goverment and the WHO about bird flu cases but not telling any of the general public.
Still that oversimplification falls wide of the mark.
Its a generalisation but probably true that if you need to make an analogy of something in order to understand it (or explain it to a 3rd party) then you (or that 3rd party) should not be commenting on that topic (the old maxim "if you don't have anything useful to say then keep your mouth shut"). Guess that explains the proble with politians...
$_="Slashdotter";$syn="OTT";s;..;;;sub _{print shift||$_};s!ash!Perl !;s=$syn=ack=i;tr+LLEd+BLAH+;_"Just Another ";_
...of the super leet who will serve as judges on a case-by-case basis. The, ahem, debugger, will submit his evidence that the company has refused to respond or address the bug in a timely manner. The panel will attempt to contact the company themselves as a last resort, and if this fails, will permit the release of the exploit. Eventually the panel will become drunk with power and corrupt, and retire in disgrace on billion-dollar yachts.
I nominate myself to head this committee.
Frankly, I don't intend to be gentle. Manufacturers ignoring security problems (or delaying fixes) for purely economic reasons aren't gentle either, and produce a lot of work for those who have to live with the crap, i.e. systems administrators. I'm not an activist either but I work as an IT consultant having to listen to all these stories, following escalations, and listing to manufacturer's managers who try to tell their customers that it's all not that bad etc. The latter folks only understand one language: pressure. I mean - what would you tell your car manufacturer telling you "eh - the fix for the child seat air bag will be available at the end of next month. By then, you should just drive carefully, okay?" Strangely, in the IT industry, everybody seems to be willing to live with half-baked solutions. I don't get it.
open (SIG, "</dev/zero"); $sig = <SIG>; close SIG;
Four, every script kiddie and their dog will have a full set of instructions on a hack to which previously only 'black hat' hackers with serious malicious intent and willing to, apparently, pay for this, were privvy.
Instead of 500 companies silently being hacked and having some of their data stolen, 5 million people, including companies, are now under attack through the latest combination of script kiddie worm + dangerous hack.
So yes, it is irresponsible to just throw the data out there - because you vastly increase the group of people who will make use of this exploit.
Just as it is irresponsible to say nothing of it.
I certainly don't know what the correct course of action to take is on -every- such vulnerability, but those involved can probably judge this for themselves case-by-case.
"Reasonable disclosure" is marketing. It's about protecting the vendor from it's customers, by not informing the customers that their systems are at risk until the vendor has a patch ready.
It makes the vendor look much better when they can see "Look, we found a bug, but we already have a patch", even though the bug has existed for years and been actively exploited for the last six months. Where as informing the customers when the problem is discovered (i.e. 6 months ago in the above scenario), to let them put in place ACLs, firewalls, etc, AND preassure the vendor to put out a patch in a week, makes the vendor look bad, EVEN THOUGH the customers were at risk only for a week, and only if they didn't took measures to prevent the exploit, rather than being at FULL RISK FOR SIX MONTHS.
Believing that the telling the world about the problem puts the customers at risk is based on the asssumption that noone else found the bug. That requires the belief that you are the best in the world. Trust me, you are not. Somewhere else, there is someone better than you, and he already found the bug. "But he could be the good guy" - well, he could, but then he would have warned the customers, and you wouldn't be the one discovering the bug, because you already knew it.
The only safe assumption is that the bug is already being actively exploited. And the only safe solution is to warn the customers, so as many as possible can take preventative measures. Even if you don't have a workaround yet, there are always preventative measures. Yanking the network cable is one such measure. Although not everybody may be able to use them, reducing the number of customers at risk is still better than nothing. Having that buggy program connected to the internet is not absolutely vital for the entire world. Some companies can do without it for a week. Others can live with having to walk over to the machine it's installed on, instead of having it connected to the network. Imagine being one of those companies, and losing a couple of millions, because NO ONE TOLD YOU to yank the cable, a job that can be done in a couple of seconds.
When we are talking about home users, it gets even easier. A company cannot do without their financial system for a week, but Joe Random User can definitely do without Windows Mediaplayer for a week, or replace IE with Firefox until his browser of choice is fixed. He may choose not to do so. By then, it's his problem. If he gets hit because you (being the guy who found the bug) kept it a secret, it's your fault. If he gets hit because he didn't read the warning, it's his own fault.
"Reasonable disclosure" puts customers at risk. Its only purpose is to protect the image of the vendor. As a security researcher that's not your job, it's the job of the vendors marketing department.
Fanatics are dangerous wherever they appear. Intelligent idiot fanatics are the worst.
Here's a fix to your example to make it more accurate:
Which is going to cause more damage:
a) telling people about the contagious pathogen that is already loose before a vaccine has been developed and distributed
b) telling people about the contagious pathogen that is already loose after a vaccine has been developed and distributed
You see, the vulnerability already exists. Disclosure is all about telling people so they can take precautions such as implementing workarounds and disapling services.
Bzzt. Wrong. Bugs are not at all like pathogens. The exploitation of bugs is like a pathogen. Exploitation only occurs with knowledge. If you can't see that, you're far too simple to be worth talking to. Of course, you probably realize your mental limitations, which is why you are too cowardly to put a name to your statements.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
What a charming oversimplification!
A security bug is only a problem when someone knows how to exploit it. While no person knows how to exploit it, it is not a problem, and no problem is persisting.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I initially intended to use the analogy to show why extraordinary claims require extraordinary evidence. It had enough parallels with the topic at hand, though, that I used it to further clarify my argument. I did this not because I don't understand the realities of computer security (in fact, my livelihood depends on my expertise on the subject), but because the person I was addressing seemed to be having trouble grasping the subject.
Avoiding all analogies, the best mathematical model I can come up with is that the damage inflicted due to a vulnerability is proportional to the number of people who have the knowledge required to exploit it multiplied by the amount of time each person has knowledge required to exploit it.
So... more people knowing = more damage. More time unpatched (while at least 1 person has the knowledge) = more damage. 0-day disclosure increases the #ofPeople factor dramatically. So dramatically that it dwarfs the risk exposure caused by a few weeks of increased time.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I am a firm believer in altruism, and I think all of the moral and kind "security firms" out there disclosing bugs and vulnerablities is a great thing. My problem is some if not all of these firms are independent from the company, I would imagine that some are contracted but there are many that do it for the same reasons people get involved in FOSS. For the company to then turn around and hit the user with a subscription fee or update limitations is ludicrous.
Now you get it!
It's not severe if no one knows.
The window could be that much larger then two months.
The sliding window works both ways. Longer if it's not a problem right now, but if it's activelly being traded and used... it becomes a much larger problem.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
the damage inflicted due to a vulnerability is proportional to the number of people who have the knowledge required to exploit it multiplied by the amount of time each person has knowledge required to exploit it.
:)
Your equation makes intuitive sense, but it doesn't model an important factor - the number of people who know about the vulnerability is not nearly as important as who they are. Here are some classes of people, and how disclosure affects them:
Skilled black hat hackers: These people are often security researchers themselves, and usually have knowledge of 0day vulnerabilities which either they or their associates have discovered but not announced. These exploits are hoarded and used sparingly (so as to keep them low profile) but against very important targets like credit card databases, government identity records, etc. Since these people are experts, their exploitation of vulnerabilities is much harder to detect than the massive disruption caused by a worm or botnet attack. If the vulnerability wasn't disclosed, it would please these people, because it would mean they could continue to exploit it under the radar.
Skilled white hat hackers: When a new vulnerability is disclosed, these people often respond immediately with workarounds and patches to fix the problem - often faster than the software companies themselves. If the vulnerability wasn't disclosed, they wouldn't be able to develop fixes.
"Script Kiddies": These are the people who are interested in breaking into or disrupting computers, but don't have the knowledge, connections, or motivation to seek out 0day vulnerabilities. Instead, they find vulnerabilities that have been disclosed and try to exploit them. These people can cause serious damage in the form of worms, but more frequently cause annoying but relatively minimal levels of damage, since they have neither the expertise nor the profit-motive of a professional black hat. If the vulnerability wasn't disclosed, these people wouldn't be able to exploit it, and would have to go play outside or something
Software companies: These guys write the vulnerable software in the first place, but have a vested interest in convincing the public that it's not vulnerable. They generally give less attention to security than is needed to create a solidly secure app in order to save time, money, and increase features. When vulnerabilities are disclosed, it both makes the company look sloppy and creates more unpaid work for them in the form of patches. If the vulnerability wasn't disclosed, these people would be delighted, because it would mean they didn't have to work on a patch, and their software wouldn't be publicly blamed when professional black hats (who still know of the flaw) break into their customer's networks.
Software users: This is the general software using public, which is most of us here on Slashdot. We don't know about a vulnerability until it's announced, or often until a patch is released. When vulnerabilities are released, we often suffer from the actions of "script kiddies" hammering at our servers or sending us virus emails. These are very identifiable problems and annoyances, so they are seen as the central significant result of disclosure. However, disclosure also gives us quick patches and fixes from white hats, and usually expedites solutions from software companies. We therefore benefit from the added invisible protection against a skilled attacker who might seek to use this previously un-patched vulnerability to attack our system(s). Most importantly, it allows consumers to make informed decisions about what software companies they trust to produce secure apps, thereby creating market pressure for more secure software development practices. If the vulnerability wasn't disclosed, we would be totally unaware of the threats to our security and privacy that lurk within the software we trust. We would be safe from the obnoxious and sometimes genuinely destructive "script kiddies", but we'd continue to be vulnerable to the real threat - black hats who are intelligent, dedicated, and motivated enough to use 0day vulnerabilities to attack us.
Responsible disclosure, as defined in the industry, gives the researcher the moral responsibility to afford a vendor a reasonable amount of time to fix a flaw before releasing the research publicly.
Yes the window works both ways. That is why the word "reasonable" is used. Two months is considered reasonable for most types of software. And don't even try to condescend. This conversation has provided me with no insight. I make a career of this stuff.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Sure. You can always refine a model until you arrive at, well, the raw data you are modeling.
SKs and BHs are the people who do damage with vulnerability knowledge (VK). There are basically two cases when a researcher is considering publication.
1) the researcher is the first to discover the VK.
2) a small number of BHs already have the VK.
For #1, practicing full disclosure does a lot of damage, no question.
For #2, practicing full disclosure may decrease the time to patch (giving the small number of BHs slightly more time to do damage), but at the expense of causing many many (many) more BHs to have the VK, and all of the SKs to have the VK (which has a HUGE damage potential).
Full disclosure clearly increases damage in #1. We can't know how often #2 is the case. But for the vast majority of cases I can conceive, full disclosure greatly increases damage (vs. responsible disclosure) in case #2.
The model still holds, I think. And it demonstrates that responsible disclosure causes less damage overall.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
I've always believed in this simple procedure:
1) The problem is discovered.
2) The problem is reported to the vendor, the report including a fixed resonable date for either a fix or the date for the final fix (to allow for tough fixes). The time alotted reflects the severity of the problem - more severe results in less time.
3) When this fixed date or the vendor date (if given) is reached, the problem is disclosed regardless, complete with POC exploit if available.
This method forces vendors to take security reports seriously and it makes it THEIR problem if the the issue is disclosed before a fix is available. Aften all, if a security researcher can find the problem, so can the really bad guys and they will most certainly not advise the vendor, leaving a free avenue of intrusion that may last a long time.
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --
Those are some good points, and I'm reconsidering - you may be correct that where a single vulnerability is concerned, full disclosure has a greater (on average) damaging effect. I still disagree that it's the most responsible response, however, because I don't think that computer users should be focused only on the latest vulnerability - there's a bigger picture that's often overlooked.
Computer software today is, on the whole, extremely insecure. We may never perfect it, but it could be a whole lot better than it is now - there are very few technical roadblocks to developing far more secure software, just economic and political ones.
As long as software developers can make money from insecure software with few repercussions, they will do so. And if a standard develops where security researchers reveal bugs secretly to software developers, there will be even less incentive to develop securely in the first place - after all, if you were a CEO would you waste manpower doing bug-testing that an army of volunteers is going to do for you anyway? Would you be concerned about security flaws if you knew the public would never find out about them?
Full disclosure keeps software developers honest. It's whistleblowing, and should have the same protections as someone who reveals a safety hazard in any other consumer product. Keeping ugly issues under the table may make a particular incident go smoother, but bringing everything out in the open in front of consumers, government, and even hackers is the only way to ultimately force the software industry to reform their irresponsible practices.
I still disagree that it's the most responsible response
s/it's/"responsible disclosure" is/