51–60 of 214 posts
Earlier quoted context omitted.
It wasn't going to be fixed, you can't ship vulnerable software, it's not okay. He was in every right to publish it and to keep shaming Valve.
And Valve has ever right to ban him from their program, right?
Earlier quoted context omitted.
It wasn't going to be fixed, you can't ship vulnerable software, it's not okay. He was in every right to publish it and to keep shaming Valve.
And Valve has ever right to ban him from their program, right?
Telling a security researcher "we're not going to fix this but please keep it secret" is not a viable strategy, ever.
In the end, the researcher went public (as nearly all will, in that same situation), Valve got a hit to their reputation in the tech press, and they ended up having to (attempt and fail to) fix it anyway. Entirely predictable, and Valve looks really stupid here.
Banning people from your bug bounty problem for following the generally-accepted rules for security disclosures is certainly with in their right, but so what? It's not a winning strategy for any company.
From what I've read, the original bug involved malware already installed on the PC using the Steam client to run other code. While I'm not a security expert in any way, that doesn't seem to me like a huge exploit. If the attack requires installing malware on the victim's computer, why not just do the evil stuff directly with that malware? If that's the case and I'm not just remembering it wrong, then I could see why…
https://msrc-blog.microsoft.com/2018/09/10/microsoft-securit...
So some companies consider LPE to be serious.
a) Program has scope that doesn't include X b) Researcher reports vulnerability that falls under X c) Since it's out of scope, it's closed as N/A d) Report is locked because company doesn't want to publicly disclose a vulnerability in their system via the Hackerone platform What's the problem here? Just go with normal vulnerability disclosure. Bug bounty programs are a two way street, and respecting the scope is part…
I mean, you can't have your cake and eat it too - if you claim that a particular issue is not a bug and you won't fix it, then you have no ethical grounds to say that it shouldn't be disclosed. Responsible disclosure expects delaying public disclosure to protect the users while the vendor prepares a fix. If the vendor says that they won't fix it, then it's not only a right, but a moral duty to disclose that vulnerabi…
Earlier quoted context omitted.
Without seeing the communications it's hard to say, but "When the security researcher -- named Vasily Kravets-- wanted to publicly disclose the vulnerability, a HackerOne staff member forbade him from doing so, even if Valve had no intention of fixing the issue" sounds like more than just not being able to disclose on the H1 program.
I submitted an XSS on the tesla website to hackerone, it was marked as a duplicate. A week later, shared it with an XSS mailing list and got an angry email from HackerOne soon after. Public disclosure violates the terms of their reporting program EVEN if they reject your report. I'm really curious how much of what is reported to HackerOne ever gets and actual patch. It kind of seems like there are bunch of known vuln…
It seems weird that HackerOne put themselves in such a deeply loser position to try to be the ones to prevent submitters from revealing security issues. Why not be a neutral party, and let the companies try to enforce rules on the hackers in these cases?
I know this will be unpopular with folks like tptacek, but I've always felt strongly that bug bounty programs offer too many perverse incentives to all parties.
More often than not it becomes a tool for companies to sweep issues like this under the rug and then use HackerOne's system to force the reporters to play ball (because they want to keep getting paid). I hate this sytem.
I'm 100% behind open, public disclosure and if it were my own product in question, I would offer bounties for _public disclosures_. That keeps everyone honest.