5 ms·

The researcher can still disclose it, they just aren't going to get permission to disclose it on the Hackerone program. Most things out of scope don't get publi

The researcher can still disclose it, they just aren't going to get permission to disclose it on the Hackerone program. Most things out of scope don't get publicly disclosed as far as I know. Doesn't seem too unreasonable.

hitekker 7y ago
> Kravets said he was banned from the platform following the public disclosure of the first zero-day. His bug report was heavily covered in the media, and Valve did eventually ship a fix, more as a reaction to all the bad press the company was getting. > The patch was almost immediately proved to be insufficient, and another security researcher found an easy way to go around it almost right away. You might want to read the article.
- EnFinlay 7y ago
  I was responding to a comment that (I interpreted) to be talking in more general terms than the scope of the article.
  - danShumway 7y ago
    Even in the scope of the original comment, doesn't it create a pretty perverse incentive to allow companies to mark HackerOne bugs as WONTFIX and then ban researchers who disclose them? Isn't security through obscurity largely to be avoided? I thought the working model for most security researchers was: if it's not worth fixing, it's not worth hiding. More to the point, I thought that responsible disclosure always came with an expectation of public disclosure. The advice I've always been given is that you should never disclose with conditions -- ie. "fix this and I won't tell anyone." It should always be, "I am going to tell everyone, but I'm telling you first so you can push a fix before I do." Does HackerOne operate under different rules?
fencepost 7y ago
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.
- cwkoss 7y ago
  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 vulnerabilities idling on their platform without quick fixes. Should be interesting once the HackerOne database is inevitably leaked. HackerOne should start requiring companies pay researchers for duplicates - that the company already knew of a flaw should make them more liable, not less.
  - robocat 7y ago
    Hackers and crackers can't be controlled. 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?
    - deleted 7y ago
      [deleted]
  - yorwba 7y ago
    > HackerOne should start requiring companies pay researchers for duplicates That would create a perverse incentive for researchers to tell their friends about the vulnerability so that they can resubmit it and also get a bounty. The problem could be solved on the side of the researchers by splitting the bounty among all submissions of the same bug, but anyone else with access to the report (employees of either HackerOne or the relevant company) could try to get a share by having someone create a duplicate report. First come, first served seems like it would be the hardest to game, as the first reporter is guaranteed to have actually done the work (not counting rogue employees who create bugs to "find" and report). There should probably still be some kind of reward for duplicate reports to avoid discouraging researchers, but something symbolic like publicly acknowledging that they found a bug might be enough to provide validation.

hitekker 7y ago

> Kravets said he was banned from the platform following the public disclosure of the first zero-day. His bug report was heavily covered in the media, and Valve did eventually ship a fix, more as a reaction to all the bad press the company was getting. > The patch was almost immediately proved to be insufficient, and another security researcher found an easy way to go around it almost right away. You might want to read the article.

EnFinlay 7y ago
I was responding to a comment that (I interpreted) to be talking in more general terms than the scope of the article.
- danShumway 7y ago
  Even in the scope of the original comment, doesn't it create a pretty perverse incentive to allow companies to mark HackerOne bugs as WONTFIX and then ban researchers who disclose them? Isn't security through obscurity largely to be avoided? I thought the working model for most security researchers was: if it's not worth fixing, it's not worth hiding. More to the point, I thought that responsible disclosure always came with an expectation of public disclosure. The advice I've always been given is that you should never disclose with conditions -- ie. "fix this and I won't tell anyone." It should always be, "I am going to tell everyone, but I'm telling you first so you can push a fix before I do." Does HackerOne operate under different rules?

fencepost 7y ago

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.

cwkoss 7y ago
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 vulnerabilities idling on their platform without quick fixes. Should be interesting once the HackerOne database is inevitably leaked. HackerOne should start requiring companies pay researchers for duplicates - that the company already knew of a flaw should make them more liable, not less.
- robocat 7y ago
  Hackers and crackers can't be controlled. 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?
  - deleted 7y ago
    [deleted]
- yorwba 7y ago
  > HackerOne should start requiring companies pay researchers for duplicates That would create a perverse incentive for researchers to tell their friends about the vulnerability so that they can resubmit it and also get a bounty. The problem could be solved on the side of the researchers by splitting the bounty among all submissions of the same bug, but anyone else with access to the report (employees of either HackerOne or the relevant company) could try to get a share by having someone create a duplicate report. First come, first served seems like it would be the hardest to game, as the first reporter is guaranteed to have actually done the work (not counting rogue employees who create bugs to "find" and report). There should probably still be some kind of reward for duplicate reports to avoid discouraging researchers, but something symbolic like publicly acknowledging that they found a bug might be enough to provide validation.