Topic: Proper Protocol Of Exploits Release (Read 1219 times)

Right, I suppose I am thinking along the lines of an exploit inherent within a Bitcoin-based website, or something similar.  The OP stated that it wasn't an exploit in bitcoind itself, so I am thinking along those lines.  Something where a fix doesn't need to be distributed to many people, only on the backend of a server somewhere.

Extremely responsive. Very much so. Practically instantaneous. Fixes are often available within hours of a report. This is to their credit, and always has been. They do take this sort of thing very seriously.

However, the fixes involve checkins that are ~impossible for relatively competent outside developers to verify, or even watch for. At the moment, for example, there's no way for us to watch and see whether we are specifically an active target of whatever exploit 0.6.3 was built for, nor can we really verify whether the fix was successful or even correct, without duplicating most of the effort put into researching the issue.

Archaeological code review is counterproductive (and I'm referring to that time when "full" details of the 0.6.3 exploit become available.) MEMO also implies that whatever a true, correct fix is could be irritatingly divergent from HEAD.

For these reasons, and for future historical and forensic reasons, I think a public release in the 'weeks' timeframe is important.

As far as I'm concern, the Bitcoin developers have been very responsive to fixing vulnerabilities (in relation to their available resources). 

CVE-2012-2459 was announced nearly 3 months ago, and has reached 75% deployment. The disclosure is scheduled to happen at 77%, which I expect to be reached in a month or two. Considering that upgrades happen on a per-node basis often run by an individual human each, this "within 6 months" timeframe seems quite reasonable to me.

Why give it a specific timeline at all?  Why not just wait until the exploit is verifiably fixed?  If concerns arise about the exploit not being fixed in a timely manner, THEN threaten to release the exploit unless it is fixed by a particular date/time.

Demanding is too strong a word to get the point across delicately. I just fundamentally disagree on the nature and responsibility of exploit disclosure, perhaps because I'm aware (as I'm sure many are identically so) of the massive black market for these things which grew out of, IMO, pure extortionist tactics which poisoned the goodwill that had been built up *prior* to when such a market could exist.

I don't think he's demanding anything.  He's just attempting to define responsibility in this situation.  This is what the OP asked for opinions on.

Are you implying the damage would be irrevocable if we had a single error? I don't see OpenBSD killed just because they had 2-3 remote root exploits in the last decade.


You're demanding an independent security researcher who could be selling his exploits for tens- or hundreds-of-thousands of dollars (depending on the exploit) behave a certain way? Someone thinks that I think I am entitled to an exploit. I don't. But perhaps this is also a form of entitlement of the security researcher's time, effort, patience, and wallet?

I would think we should be glad he's waiting at all. This guy here never waits, he just releases:

http://aluigi.altervista.org/adv.htm

Is his work overall a public good? I think so. Do I think he's an asshole for not notifying vendors (at least) prior to release? Yeah. We're extremely lucky this guy isn't a Luigi.

None of those incidents had anything to do with the core bitcoin software.



Responsibility means evaluating the impact on users, recognizing that every situation is different, and that every solution takes a different amount of time to deploy.

It is not responsible to pick an arbitrary length of time for disclosure, and stick to that regardless of circumstance or feelings of involved parties.

In the past, companies or software organisations (closed and open source) have not been consistently responsive. Or, they have requested timelines which are unrealistic: many weeks, or months. Sometimes, what's been on the line are client machines whose worth is in the thousands, tens-of, or millions of dollars'. As much gnashing of teeth that exists on the part of the rhetorical vendor, the most responsible choice is to give people choice. What is worse? Having educated, intelligent people remain in the dark about a problem which directly affects their software and machinery, or letting the exploit languish in the hands of the blackhat douchebags?

And you must assume that the meagre resources of responsible researchers are a tiny fraction of the blackhat community: and this is true because blackhat douchebags sell their shit to people with deep pockets, and can fund armies of programmers whose sole job is to find and locate these. They are funded by infrastructures worth millions of dollars annually.

We on the other hand are at a significant disadvantage by comparison: so what is the rational choice? To leave us all vulnerable for a longer period of time? Or to get the details in the hands of a significant portion of people who are actually paying attention? And by vulnerable, I mean vulnerable in ignorance, too. Who's to say the vendor fixed it properly or to our satisfaction? Who has the right to deny us the right to measure and develop countermeasures of our own?

At the same time, dropping 0-days like a modern-day Gobbles can be worse. Two weeks post-notification prior to full disclosure used to be the norm.

I'm going to tell you who will complain about any exploits you release if you give people two weeks:

1) People who are happy to be the ones with exclusive knowledge, or who think enforced public ignorance makes us somehow safer.
2) People who think you screwed them by releasing an exploit into the wild because they weren't paying attention.

Give it ~two weeks. It's your exploit. People live by your timeline. Notify the vendor. Let the patch go out. Wait two weeks. Full disclosure to the public.

Far, far larger, more complex, much wealthier organisations with customers with orders of magnitude more at stake than the Bitcoin community have managed to survive far, far worse, and they're still here.

We've survived hacks on major exchanges, thefts in the hundreds of thousands of dollars, and hundreds of thousands of bitcoins.

We'll survive a responsible disclosure policy.

Responsible disclosure (edit) for a security researcher is ~two weeks (2nd edit) post-notification acknowledgement, or 4 weeks past no response.

I agree with GMaxwell.

With some other vulnerabilities found, the Bitcoin developers have establish a 77% upgrade threshold to disclose the details of the vulnerability. See https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures

To reach a 77% upgrade ratio you may have to wait up to 3 months after private disclosure.

You usually work with the parties responsible for the thing you're reporting against and take whatever timeline they ask for, unless they're unresponsive or completely unrealistic.  As an ethical party your duty is to minimize harm, and harm is minimized when things go in an orderly and well coordinated fashion, though harm is not minimized if the vulnerabilities are not fixed so it's also not unreasonable to hold software distributor's (or site operators) feet to the fire if they're not being earnestly responsive.

Fourteen days is more than enough for somethings and far to short a time for others— it depends on how complicated the fixes are, how difficult the deployment will be, the resources available to fix the issue, what the risk of exploitation will be both before and after the disclosure and the amount of damage done. Communicate carefully, listen, and keep the good of the world in mind.

Don't worry Its not Directly Related to bitcoind client


I'm in the process of validating the Proof of concept for this Exploit.


After I have verified the Exploit, and the proper effected parties are notified what is the standard waiting period for public release 14 business days?