I read the PDFs of #39132 and #51179, and first, these are very clear and well written vulnerability reports. Props to the author for that, many times these reports can be extremely hard to follow and these are shining examples to the contrary. I found them easy to follow, enough details to reproduce, and quite valid issues.
Second, I'll put my neck out here a bit and say, I find myself agreeing with the author's stance. Namely,
1) Independently discovered vulnerabilities are not "owned" by the first to discover it. As a courtesy, you may defer to another researcher, or combine your efforts, but I don't think there's any requirement to do so.
2) 90 days notice is more than enough time to expect at least a cursory response when you say, "Has this bug been fixed? Shall I go ahead and disclose it?", and then again, "This is a heads up that I will be blogging about this on March 12, 2015 i.e 90 days after the initial
disclosure unless I hear otherwise. Thanks!", and then AGAIN, "This is a reminder that this bug will be disclosed in 4 days :-)".
In Google's case, for example, it's not just 90 days notice, it's a 90 day deadline to fix. In this case, a simple, "no, we need more time, please don't disclose this" response on the 2nd issue could have avoided the whole problem.
Bug bounties, particularly a fully managed program through HackerOne, encourage Engineers to spend value time and resources investigating and writing up detailed reports of complex issues. If you sign up to run a bounty program, it's essential you give participants the time of day, like responding to their repeated inquiries about disclosing an issue.
It wasn't clear to me if the author was banned from HackerOne or just Slack's program. If the later, well, that's fine, Slack absolutely has the prerogative to invite whomever they like to participate in the program. I think they are missing out on a great contributor in this case though. If author suffered an outright ban on the platform, that would be distressing.
Lastly, if the 3rd vulnerability was unknown to Slack before author reported it, I think author should be properly compensated based on the terms of the program.
I was banned from reporting any bugs to the Slack Bug Bounty program on the HackerOne platform after reporting the 3rd bug. What's worse is that I wasn't even notified of this? Even HackerOne didn't think it was necessary to do that.
On point 1, how do they even expect a researcher to know that some other researcher has found the exact same bug if it's not disclosed yet? This seems like a fake rule whose only possible effect is to suppress disclosure.
Isn't this a "solved problem"? You publish a hash of each report when it's received (or sent, if you're the sender intending to establish precedence), then it's clear when all reports are revealed which ones were reported in which order.
It doesn't let you know what others have discovered/reported, but it solves the "their word against my word" problem...
(Of course, if they're actively trying to minimise bug bounty payouts and are prepared to screw over people attempting "responsible disclosure" to do so, they've got a lot of motivation to _not_ implement this from their side. Doesn't stop researchers posting hashes when they make reports, then the rest of us being able to verify those hashes when the bug is publicly disclosd.)
Well, they did say "no, we need more time, please don't disclose this" on the iOS auth bug. The author's response was to wait 90 days and then disclose it without waiting for the go-ahead. Is this SOP in security circles? It's certainly unusual in non-security interactions.
"Vulnerabilities reported to the CERT/CC will be disclosed to the public 45 days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors. " https://www.cert.org/vulnerability-analysis/vul-disclosure.c...
No, the author's response was to contact them again to get a status, get no response, then disclose after 90 days, all while informing them multiple times of the imminent disclosure.
It's great that they said they needed more time, but they completely dropped the ball on that communication chain, and got more than enough chances to ask him to wait.
Second, I'll put my neck out here a bit and say, I find myself agreeing with the author's stance. Namely,
1) Independently discovered vulnerabilities are not "owned" by the first to discover it. As a courtesy, you may defer to another researcher, or combine your efforts, but I don't think there's any requirement to do so.
2) 90 days notice is more than enough time to expect at least a cursory response when you say, "Has this bug been fixed? Shall I go ahead and disclose it?", and then again, "This is a heads up that I will be blogging about this on March 12, 2015 i.e 90 days after the initial disclosure unless I hear otherwise. Thanks!", and then AGAIN, "This is a reminder that this bug will be disclosed in 4 days :-)".
In Google's case, for example, it's not just 90 days notice, it's a 90 day deadline to fix. In this case, a simple, "no, we need more time, please don't disclose this" response on the 2nd issue could have avoided the whole problem.
Bug bounties, particularly a fully managed program through HackerOne, encourage Engineers to spend value time and resources investigating and writing up detailed reports of complex issues. If you sign up to run a bounty program, it's essential you give participants the time of day, like responding to their repeated inquiries about disclosing an issue.
It wasn't clear to me if the author was banned from HackerOne or just Slack's program. If the later, well, that's fine, Slack absolutely has the prerogative to invite whomever they like to participate in the program. I think they are missing out on a great contributor in this case though. If author suffered an outright ban on the platform, that would be distressing.
Lastly, if the 3rd vulnerability was unknown to Slack before author reported it, I think author should be properly compensated based on the terms of the program.