Slashdot Mirror
Full-Disclosure Wins Again
twistedmoney99 writes "The full-disclosure debate is a polarizing one. However, no one can argue that disclosing a vulnerability publicly often results in a patch — and InformIT just proved it again. In March, Seth Fogie found numerous bugs in EZPhotoSales and reported it to the vendor, but nothing was done. In August the problem was posted to Bugtraq, which pointed to a descriptive article outlining numerous bugs in the software — and guess what happens? Several days later a patch appears. Coincidence? Probably not considering the vendor stated "..I'm not sure we could fix it all anyway without a rewrite." Looks like they could fix it, but just needed a little full-disclosure motivation."
A bug only exists if the public knows about it.
I believe there is a system that forces a company into action if it delivers faulty products.
Why then, should software be any different? Do we have to force companies to take action once a bug is submitted to them?
B.
Every experiment which ends in a big bang is a good experiment.
In the threat-models used by cryptographers, the attacker is assumed to know everything except cryptographic keys and other pre-defined secrets. These secrets are small in number and small in size. Their size and their limited distribution means we can trust protocols based on these secrets.
Software that is used by millions of people is the very antonym of a secret. Compiled source is routinely reverse engineered by black hats. Web-sites are routinely attached using vectors such as SQL injection. In short, you can't assume that any of the source code is secret. Taken to its logical conclusion, you must therefore assume the worst; that the black-hats know of far more bugs than you do. In fact, strictly speaking you assume they know every bug that exists in your software.
In light of adopting such a severe threat-model, the argument over full disclosure is a non-debate. Black-hats with sufficient resources probably already know of the bug. The only people aided by disclosing it wide and publically are the people who run the software who can take evasive action. In contrast, you only told black-hats what they already know.
Simon
Somehow I don't think that too many lives are being put at risk if EZPhotoSales has a bug in its software. Now a seat buckle on a car, that's a different story...
It was aways clear to me that full disclosure is a better option simply because people react to incentives, and bad publicity creates a strong incentive for vendors to fix and patch their systems.
Nothing like fear of losing sales and yearly bonus to motivate higher management.
Full discoluse could be finding a bug and then posting it onto the first 1337 haxxor forum you can find- which most people would agree is wrong, but full disclosure after giving the software company warning can't do any harm- cos either they'll have fixed it or they wont bother fixing it untill forced or not at all.
It works in software, it works in government too. Only slimy bastards hide behind their veil of secrecy to their customers/public. Maybe one day we will have open source voting machines.
Half the lies they say about me aren't true
Cute Rush
Full disclosure results in announcing a bug not to the world, but only to people that are paying attention. Does this include all the users of that software? No, not even most of them. So who gets informed? People looking for ways to do bad things. The user's do not hear about the defect, the potential exploit or the fix that corrects it.
They are just left in their ignorance with the potential for being exploited.
The "I want to do bad things" community has the information and is paying attention. Their community gets advance information before there even is a fix and they get to evaluate if it is worth their efforts to exploit it.
The other group that gets to benefit from full disclosure is the media. Starved for news of any sort, bad news is certainly good news for them.
All in all, full disclosure is simply blackmail. Unfortunately, no matter what the result is the user of the product affected gets all of the negative attributes. Their instance of the product isn't fixed because unless they are paying attention they don't know. They get to lose support if the company decides to pull the product rather than kneel to the blackmail. If the bug is exploited the end user get to suffer the consequences.
You can think this would justify eliminating exclusions for damages for software products. There isn't any way this would fly in the US because while we like to think we're as consumer-friendly as the next country, the truth is this would expose everyone to unlimited liability for user errors. Certainly unlimited litigation even if it was finally shown to be a user error which is by no means certain. And do not believe for a moment that you could somehow exclude software given away for free from damages. If you have an exclusion for that you would find all software being free - except it would be costly to connect to the required server for a subscription or something like that. Excluding free software would be a loophole that you could drive a truck through.
Well, sometimes a programmer and a program are very much in love dear.
Occasionally, software has bugs, and the try to practice "safe bugs" and keep them secret, but sometimes the screcy breaks, called full disclosure. Due to this accedent, 9 months later, a patch will be born.
This is not about full disclosure. This is responsible disclosure. Full disclosure would be if he went to bugtraq before contacting the vendor. Responsible disclosure is where a responsible security research goes to the vendor FIRST, and only goes to the public after the vendor has had a reasonable amount of time to fix the problem.
Responsible disclosure allows responsible companies to get a fix before a flaw is used maliciously, but the researchers still get credit. With responsible disclosure everyone wins except black hats.
Full disclosure benefits black hats more than it does anyone else.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
"Got a good reason for taking the easy way out..." - Daytripper
My humor is probably your flamebait
1. Bug is reported.
2. Secretly, a team of crack programmers (or programmers on crack) develop the patch.
3. The patch sits in a repository until public outcry.
4. Public outcry.
5. Patch released... LOOK HOW FAST WE ARE!
The dangers of knowledge trigger emotional distress in human beings.
have Slashdot stories become more openly biased. I wouldn't even call this a story, it's an opinion.
Here is a PERFECT example where
a) change was needed
b) public was unaware
c) individual wanted change
d) individual alerted a portion of the public
e) change was made.
No lawyers, no State, no violation of freedoms, no taxes, no fines.
I hope whomever decides to post a bug has enough common sense to remain anonymous.
I saw the vulnerability page. They don't have access restriction to subdirectories.
/CSS/XSLT/javascript dirs.
Here's how I've solved this problem:
1) Modify the htaccess (or even better, the httpd.conf) files, so that ANY access to any of the subdirectories of the main app is forbidden. The only exceptions are: a) submodule directories, whose php files do a login check, or b) common images (i.e. logos)
2) The only way to view your files is through the web application's PHP file lister and downloader. This should be child's play for anyone with PHP knowledge: PHP has the fpassthru function, or if you're memory-savvy, use standard fopen. Make sure the lister doesn't accept directories above the ones you want to list, and for the files use the basename() function to strip them from subdirectories.
3) Any file in the PHP application MUST include() your security file (which checks if the user has logged in and redirects them to the login page otherwise). For publicly-available pages, add an anonymous user by default.
4) For log in (if not for the whole app), require https.
4a) If you can't implement https, use a salt-based login, with SHA-256 or at least MD5 for the password encryption.
5) Put the client's IP in the session variables, so that any access to the session from a different IP gets redirected to the login page (with a different session id, of course).
6) After log in, regenerate the session id.
7) Put ALL the session variables in the SESSION array, don't use cookies for ANYTHING ELSE.
I consider these measures to be the minimum standard for web applications. It shocks me that commonly used apps still fail to implement them properly.
They might not have been lying. Fixing it properly might have required a rewrite, and instead they may have been forced to include a number of slapped-together kludges with Lord-knows-what side-effects under extreme time pressure. I know what kind of code *I* write when I'm under that kind of time constraint, and I've never seen evidence in any of the projects I've worked on where other people coding under an unreasonable schedule resulted in code I didn't want to completely scrap upon examination (but wasn't allowed to thanks to my own time constraints and lack of testing resources). Frankly, I've had bugs I couldn't fix without major rewrites thanks to the fixes that other people have put in.
So, who knows? Maybe these quick patches will result in other vulnerabilities or just nigh-impossible to maintain code. I've seen it before. While its good to put a little pressure to see bugs fixed, I wouldn't say public disclosure is a secret recipe for correct and functional software when it results in embarrassing a company into getting a fix -- ANY fix -- into place ASAP.
I do realize, though, that the alternative may be the company deprioritizing the bug and never fixing it at all. Companies are lazy that way. It seems like a lose-lose scenario.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
- Initially tell only the company. If they do nothing, then release it to everyone.
- Initially tell only the company, but tell them that you will release it to everyone in X days.
- Initially tell the company and CC a few other white hats that you trust.
- Initially tell the company and CC the better business bureau, etc.
(By "CC" I'm implying that you're letting the company know that you're telling other people.)Ben Hocking
Need a professional organizer?
...responsible disclosure would also include:
- the timeline for full disclosure being given to the vendor (I don't know whether that did or didn't happen in this case), and
- reaching some mutual or community agreement on what a "reasonable amount of time to fix the problem" is for the problem in question.
That said, I definitely agree this wasn't "full disclosure", since the vendor was informed, but it wasn't necessarily responsible disclosure, either. To me, "responsible disclosure" implies that a patch is made available BEFORE the detailed disclosure of the vulnerability happens, and the discoverer/reporter and the vendor work in concert on the disclosure.
Then, the debate becomes: What if the vendor doesn't fix the problem in a reasonable amount of time? What is a "reasonable amount of time"? Is that amount of time necessarily the same for every issue in every product? (Arguably, no.) And so on.
There seem to be some false assumptions here. It is assumed the company did not look at the bug and potential fixes until after it was "fully disclosed". If they released a fix a couple days later, the more likely scenario is that they've been looking at the problem and assessing what options they had to address the problem.
Ironically, the full disclosure probably forced them to put out the solution before it was ready, leaving the risk of new bugs. IMHO, forcing a company to rush a fix is not the answer. If you work for a real software company, you know that today's commercial software often has thousands of bugs lurking, although many are very edge case and are often more dangerous to fix than not fix (esp if there is a workaround).
There should be enough time given to a company to address the issue. Some can argue whether or not 5 months is enough time, but that's a different argument. I think forcing companies to constantly drop everything for threat of full disclosure will end up doing more harm than good.
I was thinking of moderating, but I'll reply instead:
Its possible to be injured in ways other than just physically. What about fraud and identity theft? It could be very damaging to thousands of people if one of the software applications that your company is using has flaws that allow fraud or identity theft to occur on massive scale.
To quote "Going Postal" by Terry Pratchett: "You have stolen, embezzled, defrauded, and swindled without discrimination. You have ruined businesses and destroyed jobs. When banks fail, it is seldom bankers who starve. In a myriad small ways you have hastened the deaths of many. You do not know them, but you snatched bread from their mouths and tore clothes from their backs."
Theres a reason why fraud and theft can have as harsh a punishment as assault. (In Canada at least.)
Maybe EZPhoto Editor isn't going to put anyone at great risk if it fails, but I'm sure you could think of some software that might.
I'm glad you said that and not me. I was about to write a dissertation on security and disclosure based on the the SEC's stance and requirements. Citations and everything.
"Little is much when little you need."
"Coincidence? Probably not considering..."
Yeah, everyone knows that patching security holes is an instant process. What other explanation could there possibly be? The public found out about the bugs, and the vendor waved a magic wand, and presto-changeo, they were fixed.
Okay, now let's be real here.
That the patch appeared almost immediately after is the surest sign that the vendor was already working on them. It probably also indicates the vendor wasn't confident that they were finished, and rushed them to get them out after only a couple days of public disclosure.
So enjoy your half-baked patch.
There seems to be this strange notion that blackhats benefit from full disclosure.
The thinking seems to be something like this: when a bug is disclosed, blackhats that were unaware of the bug become informed and have a window of exploitation until the bug is patched.
This seems absurd to me. As soon as the bug is disclosed, users become aware and can immediately block the vulnerability. If there is no other solution, they could at least stop using the vulnerable software. So the window of exploitation is the amount of time from the disclosure to widespread awareness and shutdown of buggy software.
Some would say that it is over-simplistic to think that you can just shut down vulnerable software. Some might claim that it just isn't practical. I think what this argument really means is that it could be very costly to some enterprises to have to shutdown some vulnerable systems. The system administrators would have to weigh the costs of shutting down against the costs of being exploited.
Full disclosure is really just an economic issue. Full disclosure highlights the costs of using buggy software. Distributors of more buggy software may not appreciate the reflection on the total costs of using their software. Some businesses and people may not appreciate the forced realization of the total costs of the software that they use.
Some people may tweak their bathroom scales to make them feel better about the total costs of their dietary habits. But they shouldn't rant about standard, untweaked scales being unethical in their methods of disclosure.
If the truth about the software you develop or use is uncomfortable, don't try to cover it up. Hiding your eating disorder doesn't solve the problem.
You can't make the best economic decisions unless you recognize the true economics of your software choices.
I'm not familiar with the software in question, but are they meaning to say that the company did nothing for a month, then they posted the vulnerabilities publicly, and in less than 7 days the company became aware of the post, tested the vulnerabilities, designed a solution, corrected the code, and had a software update tested and ready for deployment?
If so, that is some AMAZING response time. But I would venture a guess that they had already been working on the corrections. The public posting may have made a couple of coders work over time, and cut the testing phase out of the cycle, but for them to do the whole thing in less than 7 days is highly unlikely.
Not only that, but since they would have either had to cut short, or cut out entirely the testing phase of the release, it is MORE likely that security issues remain, or that new security issue have been created and not found.
I'm not sure I'd call this one a "win" just yet.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Forget morality for a minute... Making the bigwigs at some major company cry out "OH SHIT" in unison is one of the few sources or free entertainment I have left.
Ten to one, we hear next week that some large repository of Student papers is vulnerable too.
The reason the attackers are keeping their work secret is usually for two reasons (1) they want an advantage over other attackers, to be the first to break it really thoroughly, and (2) they don't want the AACSLA to plug any holes before they can find a break that will be impossible to plaster over.
Also, that's a poor example because a lot of the AACS hacking goes on in the open. When a break is found it's usually documented (at least if you go to the right forums). They're not sending it to the AACSLA to fix, but it's not really all that 'secret,' it's more like academic research where the research is conducted behind closed doors, but the findings get published when there's something significant.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
We don't even have 'open' elections anymore. No matter what the deal is with machines, punch ballots and the like the ballots will just be destroyed after a judge says not to.
Welcome back to the USSA!
Get your Unix fortune now!
Full-disclosure has to be in place. Other wise these companies would never fix the problem. Well because it cuts into the bottom line and in effect costs income.
Companies only care about their bottom line. Brand identity and other priorities are all directly related to their profitability and thus everything comes down to the bottom line.
7 .html.) The USCPSC keeps them in check to ensure even cost-prohibitive measures are taken when it comes to protecting consumers. Then again, we are talking about injury, death and mitigating a $700 billion/year loss in the US attributed to defective products so I do recongnize it's an extreme example. However, it illustrates that even when the stakes are high companies still only care about the bottom line so don't expect software companies to be any better.
1 0.htm.) They estimated a third could be elminated through improved QA. Companies compared the cost of improving QA to the anticipated reduction of product-defect related expenditures and when the numbers weren't there they passed.
Looking at an extreme example such as our children's welfare, the USCPSC (http://www.cpsc.gov/) deals with product safety but does have a focus on children. If it wasn't for this commission the toy industry would be in far worse shape with respect to safety than it already is. Mattel isn't the only company using cheap Chinese labor with little to no QA to keep their profit margins up. They, too, have a team of actuarial dorks showing them how their bottom line is dramatically improved using this model and risking the occasional big hit (http://www.cpsc.gov/cpscpub/prerel/prhtml07/0725
The NIST put together a report in 2002 outlining the cost of software errors to the US economy and recommending some next steps (http://www.nist.gov/public_affairs/releases/n02-
Granted, a commission would only be a start and apply solely to US companies. However, you can bet that consumers will remain at least as ignorant about their software as they are about the chemical composition of the toys their kids are chewing on. You can also bet that software companies will remain at least as irresponsible as their toy industry counterparts. Seems to me a third-party is the only way however it has to be legitimate, centralized, credible and well communicated. I think the MoAB, MoKB and other LMH projects showed how these principles could work even if a number of fixes came from the community and not the companies themselves.
Until then I say responsible disclosure is the way to go with full disclosure after 30 days if it's not fixed or at least officially communicated to the public by the developers. If you drive over a failing bridge as part of your commute would you want the city to withold this information for fear terrorists will exploit it? Sure, you say "close it" but that's like saying a company should "recall the software" until it's fixed. You say "don't use the bridge" but that's like saying a company should stop using the software. Sometimes these are options... sometimes they're not... but if you're not for disclosure it's like saying the city should keep quiet until they're ready to fix it.
That's just my POV... no more, no less.
Oh, you're not stuck, you're just unable to let go of the onion rings.
Since if you have FOSS with all needed to build and install the product yourself, there's no *need* to have product liability on it. With CSS you must wait until the autor company makes the changes since there is no way you can do it. In that case, there *is* a need for product liability.
You can then decide to pay for keeping your source closed in liability for the code you closed or absolve liability by freeing your customers to fix yuor prohlems.
NOTE: this DOES NOT mean GPLing your code. You can keep it protected fully just allow the owner of the code to work out how to fix the problem and tell others to (e.g. make a patch diff) which, since it is personal use and not an action removing potential customers, is not (or should not) be copyright controlled in any case.