so I’d like to make a proposal of process relative to the handling of contrib extensions when a security issue is reported but the extension is not really maintained anymore.
The general idea for me is that in such case we should:
Wait a bit after the report to try finding someone to handle the fix / to try contacting the reporter
After the delay create a CVE and disclose it without patch
Even before disclosing it, if we know there’s a security issue we should find a way to inform users / discourage them to install such extension
For 1, it’s probably about checking the recently opened security issues: we currently have a dedicated mails sent to security ML whenever a new security issue is opened, we should maybe document this in the policy as we’d need to ensure to keep it, so that we cannot miss a security issue opened on a contrib project even if we’re not actively contributing to it.
For 3, we probably need new metadata in exo in the long run, not only for security, but also to inform that an extension is deprecated or not maintained anymore. In the meantime, I would propose to use the summary of the extension which is visible in Extension Manager, to output the fact that an extension contains a known vulnerability when it’s the case. We could even perform a try to use emoji to be visible. We could also change the name of extensions in such case to add a flag e.g. [UNSECURE] My Extension.
And of course, if it happens we need to ensure that any recommended flag is removed.
+1 to improve this, but while it would be nicer to see the state of the extensions being reflected in the extension manager, it’s independent of the handling of the security of unmaintained applications.
+1 to stop recommending extensions with no (security) maintenance.
Yes it would be nice to list known CVEs affecting extensions in the EM and to mark extension versions with some warning (and even ask for installation confirmation) when there are known CVEs affecting them (and with a criticity color depending on the CVSS score probably). We need to brainstorm how we could automate this to the max.
We’re not supposed to use the recommended concept anymore since it’s been moved to a “supported by” concept. I think “security issues” and “supported by” are orthogonal. An extension can be marked “supported by” someone but still contain security issues (especially in a given version - remember that the EM allows installing all versions, not just the last one).
My point was to hide the extensions from EM results as long as a known vulnerability is not handled.
Well, AFAIU “support by” means that somebody is maintaining it, so in theory we should never be in such case. But if one day an extension with a “supported by” metadata receive a vulnerability report and the maintainer is not here anymore to answer/fix the vulnerability, IMO we shouldn’t keep the supported by flag, at the very least until a new version containing the vulnerability fix is released.
Not exactly. “Supported by” means that we delegate the quality of this extension to someone else. And that someone else has his/her own timetable and can decide to fix security issues quickly, slowly or not at all. However on the XWiki.org side we need to tell our users what extensions have open security issues affecting them independently of the quality of the external support (it’s a best effort since we don’t necessarily have access to extension’s issue tracker for ex and CVEs may not have been created. So the best effort is probably to report open CVEs if they exist, on the extension id and on its deps). That’s why the 2 concepts are orthogonal. Also, as I mentioned we also need to do that for old versions of extensions (even if security issues have been fixed).
It’s not controlled by us and we have an agreed rule that all supporters must renew their pledge every year. We just haven’t implemented the renewal process yet.
We already know how to find the CVEs impacting a given extension version, that’s what https://extensions.xwiki.org/xwiki/bin/view/Extension/Extension/Security/UI/ does. It only checks actually installed extensions right now (it’s just a filtering criterion, it does not need it to be installed to check it), but it could as easily check others (for example compatible ones which are stored in the EM local index).
I think the important thing is that we need something that works right now for already released versions of XWiki. I’m definitely +1 to implement this in the security vulnerabilities extension and to deploy that, but it takes work as we need to be careful what message we send to users.
An important question is also what we do if an extension doesn’t have any vulnerability but depends on either a) another extension in our extension repository that has a CVE, or, b) an external dependency that has a CVE. In the first case, we should probably warn admins, in the second case we should probably only warn admins when there is an update that needs to be installed or when the extension is unmaintained. Otherwise, we should give the maintainer of the extension the possibility to react first and provide an update before we warn admins. For this, we would also need a system to alert us/the maintainer of the extension before we alert the admins. Further, there is also the possibility in particular for external dependencies that the extension actually isn’t affected by the vulnerability.
Due to this whole complexity and the fact that we’re in the situation that we need this possibility right now and not maybe in the future, I’m +1 to start with a manual process of changing the extension description and name (btw., unsecure should be insecure I think, see also Unsecure vs. Insecure: Do They Mean The Same Thing? (Read This First!)). I also expect that we need to do this manual step once per extension, so I don’t expect it to be much work, in particular compared to the already manual process for publishing a CVE.
Coming back to the original proposal: +1 for 1, 2, and 3.
Regarding the timing I would suggest something along the lines of:
Send a direct email to the maintainer to ensure the maintainer is aware of the security vulnerability if we can’t reach the maintainer directly, e.g., on the chat. Inform the maintainer about our security policy and in particular the following steps.
If there is no reaction after 30 days, warn on our private security channels and add a generic insecure marker to the extension. If we get a negative response (i.e., the maintainer doesn’t commit to fixing the vulnerability), warn without further delay.
Three months after the warning, publish the CVE and Jira issue with full details (using the security advisory application for scheduling).
If the maintainer intends to fix the security vulnerability but doesn’t fix the security vulnerability within the timeframes mentioned in our security policy (that depend on the severity), a vote on the security forum can decide to follow step 2, and possibly also step 3 if there is still no fix.
I think the “long run” has more to do with reusing the Security Vulnerabilities Application tools to list CVE impacting an extension. In the meantime, we should focus on what does not require implementing something new (i.e. I don’t think it’s a good idea to introduce some dedicated property in exo for this), so +1 for the warning in the summary (note that this means either update it in the pom and do a release, or introduce a way to force a custom summary which won’t be overwritten by imports).
Sounds good.
One thing that was not mentionned is the version range to put in the CVE when nobody stepped in to fix the vulnerability, and I would suggest to indicate a range that include future versions too, and then if it’s eventually fixed, the range should be modified in the CVE. The reason is that there is very good chances that while nobody wants to fix the vulnerability, the extension still continue to have changes and new versions for other aspects which might not be impacted.
Isn’t the summary cached in the local extension index? If so, is there a way to force an update from the extension repository without releasing a new version?
+1 for the proposed strategy, with Michael’s suggestions.
That’s indeed another problem. Currently, the extension index assumes that the summary of a released version does not really change, so it won’t update it at next refresh (it only updates stuff which don’t come from the pom, like the rating support status).
emoji to be visible. We could also change the name of extensions in such case to add a flag e.g. [UNSECURE] My Extension.