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.
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
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.
This is a very odd point of view.
First of all, if the users of the software aren't paying attention, who's fault is that ?
Secondly, you would think and hope that the software manufacturers would be paying attention and that they would inform their users, who may or may not be paying attention.
Full disclosure doesn't just imply disclosure to a small, specific group of people. It involves making information PUBLICLY available to EVERYONE. If someone isn't paying attention then that's their own fault. But if you don't feel like end users who are too worried with other things to be paying attention to Bugtraq are getting a fair break then point the finger at the software manufacturer instead. After all, they're the ones who sold faulty software and they're often the ones who continue to sell faulty software when bugs are not disclosed to the public, because they take the mind set of "what they don't know can't hurt them".
Unfortunately, what "they" don't know CAN hurt them. Because those same people you were talking about who are "interested in doing harm" are usually the ones to find the bugs to begin with. So they already know and those end users that you are so adamant about protecting are already at risk.
So IMO it's the responsibility of the software manufacturers to pay attention, fix bugs, release patches and inform their users that they need to apply said patches ASAP.
I mean, are you really advocating keeping information from people ? What if you had cancer, would you prefer that your doctor not inform you ? As I already stated, full disclosure is all about making information publicly available to absolutely everyone, so that absolutely everyone can make whatever choices they feel like with that information. Your argument is that full disclosure is selective about who it makes the information available to. I have to disagree. At the very least it makes the information available to the developers who made the buggy software to begin with, and competent admins who follow those lists so they know what kind of bugs are running on their servers (I used to be one of those).
have Slashdot stories become more openly biased. I wouldn't even call this a story, it's an opinion.
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.
"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.
If the company was indeed looking at the problem, then they lied about it. Their response to being notified of the problems, as described in the article, was to say "Gee, we're not going to bother fixing that. Instead we're going to work on a new product and just sell it as an upgrade to everybody."
When someone tells you flat out that they aren't going to do anything, why is assuming that they aren't doing anything false?
Someone mod the parent up!
"Little is much when little you need."
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.