I’d like to improve our security policy for adding new best practice regarding the way advisories are written to prevent providing a clear proof of concept for reproducing a vulnerability, even if those are available in the jira ticket.
The rationale is that according to @C-Iaens we’re seeing in the wild scanners importing automatically CVEs and search for PoC to try reproducing them automatically. My understanding is that it’s ok to keep them in JIRA for now: they’re useful for us for fixing, and even if we chose to remove them here they would be available in the history of the tickets.
So my proposal here would be to edit the security policy to:
Add a warning in the Security Advisory template and information section to ask people to avoid putting clear reproduction steps of the vulnerability
Add a sentence in the template with same information
I agree that ready-to-use PoCs should be avoided in advisories, but I would not overestimate the protection this provides. Drupageddon is a good example: the SQL injection was fairly easy to derive from the patch itself, even without AI-assisted analysis at the time. It was exploited within hours of disclosure, leaving most administrators around the world with virtually no realistic time to react.
For extremely critical vulnerabilities, the more important question may therefore be disclosure timing and coordination. EFAIL is a good example of a deliberately coordinated disclosure where users had to be warned before all technical details became public.
In exceptional cases, the responsible message may effectively have to be: “Take this service or feature for critical systems offline tomorrow; we will tell you why the day after.”
In retrospect, Drupageddon was arguably such a case: once the patch was public, the vulnerability and its exploitability were effectively disclosed as well.
So I support avoiding PoCs in advisories, but for highly critical vulnerabilities there should also be a process for staged disclosure, rather than assuming that withholding reproduction steps buys much time. There could be, for example, an explicit flag on certain security tickets indicating that staged disclosure is required: first a warning, followed by the usual disclosure process.
Such a flag could be required by default whenever a working PoC is provided for a highly critical vulnerability.
Yes for sure, we work closely with XWiki SAS for the disclosure of our vulnerabilities already. So far I haven’t got report about other companies (sponsored or not) that should be more involved, might be something to work on in the policy to have a transparent procedure.
Interesting, I guess we could have sometimes a 2-stage disclosure process where we would provide the PoC after some embargo time after the initial embargo. However I see 2 possible issues:
obviously it’s a more complicated process with more work for the handler of the security issue
PoC are also used e.g. for QA teams to assess that a security patch works properly, so it means having multiple tickets with different level of information, or not disclosing the ticket when performing initial disclosure
In any case, I wouldn’t go there as a generic rule: I think for us doing it only on a case by case basis should be enough.