Security Vulnerabilities Application improvement to make it recommended again

[mleduc]

Hello all,

The results below are following a discussion we had with @caubin, @lucaa, and @tmortagne.

Currently, the identified issues blocking Security Vulnerabilities Application as part of XS are:

1. the notification bell turns red as soon as a CVE is published, before we have time to review it
2. the notification bell turns red even if there is nothing they can do (i.e., there is no fix release)

This is leading to confusion for admins, which then turn to this forum, or commercial support for explanations.

The general idea is: only show the red bell when an upgrade action can be realized by the admins:

• upgrading an extension from the EM
• upgrading the XWiki instance to a newer version

Proposed changes:

In the UI

• By default, CVEs without an applicable upgrade are hidden, a toggle allows making them visible
• Introduction of a configuration of the latest accepted version of the core
  • default: empty — all stable versions are accepted
  • LTS: all ‘x.10.z’ versions are accepted
  • x.y.z: all version up to x.y.z are accepted (this can allow an instance admin to limit the notifications to a version range they control)

In the security scan

At the end of each scan, looks for a compatible higher version where the CVEs cannot be found.

To do so we first list all the direct dependencies which are directly of indirectly impacted by a CVE.

For each we check for the most recent compatible version, and propose to upgrade if at least one CVE is removed by the upgrade (we should list the CVE actually removed by the upgrade, and which remains).

For installed extensions, we propose to upgrade manually through the EM.

• If this lead to changing the major version, a warning must be displayed
• If this lead to only a partial fix (i.e., some CVEs remains), a warning must be displayed

The notification bell turns red only if at least one extension is found with an applicable upgrade.

Let me know if something else needs to be done in order to make this extension recommended again. And, of course, if you have some remarks or questions regarding this proposal.

PS: In addition to this technical proposal, I’ll make some smaller proposals with textual explanation to make the UI more self-explanatory in the following days.
PS2: We will still keep the automated test we are currently running to keep upgrading dependencies as soon as possible, and document the false-positive.

[caubin]

Hei,

I’m wondering if it would be valuable to make the notification from a security vulnerability dismissible by the admin ; WDYT ?

It would mean that even if we show the notification bell in red, for example from an extension that has a CVE, then the admin should still be able to acknowledge the issue and, either in his notifications or in the administration of the wiki, dismiss the notification.

If the bell stays red all the time, then admins may not see that another CVE has impacted their wiki for example.

Thanks,
Clément

[mleduc]

@caubin

If the bell stays red all the time, then admins may not see that another CVE has impacted their wiki for example.

In theory, the bell shouldn’t stay red “all the time” as it’s only red when an upgrade is available (and therefore, should be applied to remove the error).
But, I can imagine situations where a given upgrade can’t be applied, or a workaround is manually applied instead of upgrading. So +1 for that.

[MichaelHamann]

In general, +1 for this proposal but there is one point with which I don’t agree: I think if there is an extension that has either a) been explicitly installed by the user or b) has been installed as a dependency, but is no longer a (direct or indirect) dependency of any explicitly installed extension, we should display all CVEs for such an extension with the recommended action to remove the extension. The reason for this is that we should have a way to send a clear message that a certain extension or no longer used dependency poses a security threat to the instance and should be removed. As noted, such notifications should be dismissible but still, I think we should display them.

There are two cases here where this could happen I think:

1. We drop a dependency because it has a known vulnerability but during upgrade, the admin decides to keep it when offered the question if it should be removed. Ideally already at this point but in a first step during the next security scan, the admin should get clear instructions to remove this now unused dependency that is posing a security threat to the instance.
2. We get aware of an extension that is no longer maintained by us or was contributed by a person we don’t know that is not maintaining the extension (anymore) that has a security vulnerability. As we cannot possibly fix security vulnerabilities in all community-provided extensions, after some time, or if we get aware that the vulnerability is exploited, we create and publish a CVE for this extension without offering an upgrade. This should push admins to remove this extension. We should discuss the details of this process. Most likely the process should include first notifying the developers of the extension, then some embargo time, and maybe the CVE should contain fewer details than we normally include. I think it is important that we have such a process, in particular in case the vulnerability is exploited by malicious actors to have a clear way to warn all affected admins.

[mflorea]

+1, including @MichaelHamann 's comments.

Thanks,
Marius

[mleduc]

@MichaelHamann

I think if there is an extension that has either a) been explicitly installed by the user or b) has been installed as a dependency, but is no longer a (direct or indirect) dependency of any explicitly installed extension, we should display all CVEs for such an extension with the recommended action to remove the extension. The reason for this is that we should have a way to send a clear message that a certain extension or no longer used dependency poses a security threat to the instance and should be removed.

1+, assuming we can accurately identify such extensions with the data we have.

@MichaelHamann

There are two cases here where this could happen I think:

While accurate, I’m unsure how we can programmatically make exceptions to the “only turn the bell red when there is an upgrade available” for the two cases you propose.

For case 1 I guess we can keep track of how the extensions ended up as a direct dependency, and make en exception if the extension became a direct extension after an upgrade.
For case 2, what do you think would be the criteria to turn the red bell and suggest the “uninstall” action specifically?

[MichaelHamann]

@mleduc

For case 2, what do you think would be the criteria to turn the red bell and suggest the “uninstall” action specifically?

My first thought is that we don’t need this as we’ll never publish a CVE without having an upgrade available unless we want to suggest the uninstall action. So whenever a top-level extension has a CVE and no upgrade available, suggest removing it.

Thinking again, I’m wondering if there could be a case where a third party releases a CVE targeting an XWiki extension without our consent. So maybe there could be an extra safeguard that if the CVE targets the XWiki namespace we ensure that it has been published by us, e.g., by verifying that it’s identifier corresponds to the GitHub repository that hosts the extension? For extensions that are not using an xwiki.org or xwiki.com namespace, I fear we’re out of luck and need to trust the CVE data. We should have the possibility to “block” the CVE through our CVE analysis feature, though. This would only affect top-level extensions that don’t originate from XWiki which should be rare. In case this should change in the future, we could always add verification steps for other organizations, too.