Responsible Disclosure - Old Debate, Fresh Aspects?!
Posted by jericho
Earlier this evening, there was a Twitter debate regarding a proposed standard for responsible vulnerability disclosure. It referred to ISO/IEC 29147, a proposed standard for responsibly disclosing a vulnerability. @dinodaizovi brought up a fresh angle, that the "responsible disclosure" name itself completely ignored the aspect of the vendor practicing "responsible remediation". That term should really be more in the center of our minds and discussion. The lack of "responsible remediation" is why so many researchers are fed up with dealing with vendors. That is one reason some use services like ZDI or iDefense, not just the cash.
The "responsible disclosure" debate is stale for the most part. We'll never agree on how much time is 'right' for a vendor to fix a vulnerability. Some researchers think it's days, other think weeks or months. In the paraphrased words of some female vendor on some boring responsible disclosure panel a few years back, "if i can have a kid in 9 months, i should be able to fix a vulnerability too". Yet 9 months isn't reasonable to some vendors like HP, who routinely break the 1,000 day mark, even for simple XSS.
@mckeay brought up another aspect to the responsible disclosure debate that was actually fresh, asking what part consumers played in the disclosure process. While I believe it is a neat aspect and something most haven't considered, I personally believe it is quickly answered by "consumers can put financial pressure on vendors that don't play well with others". In reality, consumers are lazy. It takes more than a few bad acts to get us to spend time an energy finding a new vendor. Short of anally raping us with a router and pouring lemon juice in our festering wound, nine times out of ten, we will not find a new vendor.
Back to @dinodaizovi. He is right, any standard for disclosure should be equally centered on the vendor as it is for the researcher. Researchers can easily fall back on RFP's "rfpolicy" disclosure policy and change X days to something they believe in. The framework is still perfectly valid and outlines the process, the time frames are always up for debate.
What if we carried this one step beyond? How about making the ISO standards apply to any and every vulnerability, regardless of who found it? If BigVendor finds a vulnerability during internal testing and fixes it, don't consumers have a right to know? When BigVendor says "upgrade to Service Pack 18" and only gives us a reason of "big stability enhancements!!", shouldn't we have a right to know those enhancements translate into 17 remotely exploitable vulnerabilities discovered during internal testing and QA? Wouldn't *that* knowledge be a more significant reason to upgrade and apply the service pack?
I realize it is a pipe dream to think that most vendors would ever offer that level of transparency, even months (years?) after a given issue is fixed. In reality though, they are the proverbial large mythical flightless birds who stick their heads in the sand rather than face a difficult situation (ostriches are real and don't bury their heads). It has been proven countless times that serious vulnerabilities in big vendors (e.g., Microsoft, Apple, Adobe) are being discovered by multiple parties. No one with an inkling of common sense and rational thinking can believe that the 'bad guys' aren't also discovering some of these bugs. We're long past the point of vendors honestly thinking that they can get away with some notion that they have a reputation for 'security'. Add it up, and we're to that time where the big vendors should be disclosing vulnerabilities discovered during their internal QA / SLDC process. The reputation of insecure software really can't hurt them any more, and transparency is finally the one thing that could buy back some degree of consumer confidence.
Perhaps now is the time where 'responsible disclosure' should apply equally to hackers, security researchers and vendors, as well as apply to 'responsible remediation'. Because really, some 20 years after the disclosure debate got going, do we really think we need to try to apply more guidelines to researchers giving away $250/hr consulting work or "hackers" posting vulnerabilities as a hobby? Vendors that have tried to label or apply policy to these people were simply blame-shifting from day one, while not applying that desired policy to themselves.
The idea of ‘responsible remediation’ is a rather good semantic shift and I like what it implies about vuln resolution being a shared process between researchers/reporters and affected product vendors….. but the underlying sociological problems remain. What does ‘responsible’ mean, and to whom and under what circumstances? Who makes that determination and when? (Remember what Justice Potter said about indecency: “I’ll know it when I see it.”)
Until those social factors/considerations get resolved (yeah, right - we’re all human, and even companies are run by humans out for profit and power) this cycle of finger-pointing over the ‘best’ way to conduct vuln disclosure will continue, as will the assorted mistrust and bad blood surrounding this issue within the cybersecurity community.
An ISO standard won’t be the answer.
This is a discussion that we discurs for long time. In my case depending on the type of vulnerability, i wait X time or XXX to make it public, but it is also true that the researchers looked for a relationship & collaboration with developers, but these always distrust and in my case no have respond to the advisor or when they have do, only Microsoft has asked me not to reveal information to try to protect users.
1 - the vendor should first when a researcher reports a vulnerability , ask to not disclose details about vulnerability, if this is not requested, the researcher is free to make it public when he want.
2 - The developer should also recognize in their change logs to the researcher and give due credit.
3 - A vulnerability should not be years without being patched, it’s like buying a car and it have a manufacturing defect, before which the manufacturer tells me there is no single solution … instead of putting up with that car, should not I also be able to return and that I reinstate the full amount of the same?
4 - Many products are open source, and the researcher whenever possible apart from reporting the bug, should the extent of its ability to offer possible solutions if it is in his hands.
As I said this is something we have long discurs and it is difficult to reach consensus.
Developers should thank the hours we spent looking for these holes. not everything in life is money, it is quite often with simple thanks, which besides helping them debug their products do not give us the most times.
Sorry for my bad english.
Personally, I think that a four to six month timeframe should be appropriate. Especially if the person(s) reporting the vulnerability include some type of Proof of Concept with the report. Four to Six months gives the vendor plenty of time to analyze the PoC and try to fix the issue.
It also demonstrates responsibility on the part of the researcher. They give the vendor enough time to publicly acknowledge the vulnerability and either provide a solution or a workaround.
In the end, after you report it to the vendor, the responsibility falls upon the vendor to fix the problem. The idea that companies like Microsoft ask you not to reveal the details until they have a fix released is ridiculous. That is why we’re in the situation where some vulnerabilities are unpatched years after they’ve been reported.
If the vendor knows that within four to six months the vulnerability will be revealed (along with any PoC), it will put a fire in their ovens to try and fix the problem quickly.
Have a great day:) Patrick.