Disclosing a non-bug

[alxbrsn]

Hacker publicly discloses details of a report that was previously submitted to a team. However:

• the team/platform has rejected the report as invalid OR
• the bug has already been confirmed to be fixed

Resolution: A platform ban seems excessive in these situations. A warning or a temporary program ban should me more than enough, given the very low risk of the disclosure being dangerous.

Standardizing a trivial punishment or no punishment for these situations would incentivize more accurate triage, and would probably remove a lot of friction from the process of publishing research.

[hakluke]

I think that if the program team has rejected the report as invalid, it should be able to be publicly disclosed without any punitive measures, simply because according to the program it's not a vulnerability, meaning that nothing is being disclosed.

It's a trickier case if a triager rejects the bug or marks as informative due to a mis-triage, because in this case it is likely that the program would not have even seen it. So what might end up happening is high severity bugs get disclosed, and the organization suffers even though it wasn't their fault.

I agree that it would make sense to standardise different levels of punitive measures depending on the situation, e.g. disclosing an unresolved critical bug on twitter 1 day after reporting on platform is vastly different to disclosing a low severity bug after it has been resolved.

I think this brings up a whole other question about disclosure too - how amazing would it be if all resolved bugs were able to be disclosed publicly! Unfortunately I just can't see a lot of orgs ever agreeing to that.

[infosec-au]

Unfortunately platform code of conduct prevents disclosure of issues even if they are not accepted by a program. I had this issue last year with a program where I was threatened with a program/platform ban because I disclosed an issue that was marked as informative.

[hakluke]

Ah, I see what you're saying. So what do y'all propose the resolution is?

i.e. when should it be okay to disclose?

Maybe:

• When the program rejects the bug as informative/NA
• X days after the bug is marked as "resolved"

Any other times?

[edthedev]

Great discussion.

When this reaches final draft, I would encourage avoiding the word 'punishment' and using 'incentive' and 'disincentive' instead. No player in this scenario deserves 'punishment', but everyone benefits with incentives that drive toward better outcomes.

[jcaluwe]

@hakluke : "because according to the program it's not a vulnerability, meaning that nothing is being disclosed."

The problem is that in most T&C's definition of a "Vulnerability", it does not state WHO needs to conclude it's a vulnerability. "Vulnerability" is defined by the harm it can cause. So if the researcher thinks it's a vuln, and the program does not, the legal term "Vulnerability" still applies. If the researcher is correct (and that's the outcome (s)he hopes to achieve), the vulnerability can cause harm, meaning it wasn't legal to disclose. Regardless of what the program owners thought it was.

This needs to change.

For me, unilateral disclosure should apply only to the "too complicated or unlikely to be exploitable" or "It's a feature, not a bug" excuses some programs use to avoid payment. Rejected (NA/informative) bugs should be disclosable, if only to force program owners to think twice (thrice?) before rejecting something they maybe barely understand.

Rejecting a bug should imply renouncing any and all intellectual property claims on the submission. You, the researcher, signed away those IP rights when you clicked "I understand", remember? Rejecting a bug should imply renouncing any claims to the term "Vulnerability".

This can only apply to public programs, otherwise you would disclose the existence of a private program. Which would drive programs to become private, which would be good for the platforms. That in turn might be an incentive for the platforms to get behind this change to the T&C.

For non-bugs, program owners shouldn't be afraid to reject, if they are confident in their assessment. For complex bugs, they should at least pay minimum bounty, to err on the side of caution.

off-topic: Today the only rights we have is the safe harbour, in part or full, per the T&C's of the platform and the program details. Back in the day, that was a big deal. In Belgium, safe harbour is now established law. Other EU countries will follow, in context of the EU NIS2 law that is coming. In time, we should claim our IP rights back. We are the authors, we are the talent. This would give us control over what happens with our bug, beyond disclosure even. Before program owners start realizing they can sell our techniques & payloads to commercial scanners and AI-powered WAF's.