Display security issues directly inside XWiki Standard

Development
#1

Hi devs,

In an effort for our users to be safe and thus upgrade to XS version that fix security issues, I’d like to propose the idea of developing an extension bundled in XS that would display somewhere (to be defined, see below for options) the list of security issues that exist for the current wiki.

The list would be computed using:

  • The list of published advisories on GitHub (using GH’s REST API). See Repository security advisories - GitHub Docs
  • The current wiki version. Note that even if the wiki has been patched to fix/work around a given security issue, it’ll still be listed since the wiki version will not have changed.

Some options/things to consider:

  • Only list security issues having a CVSS > some value. For example 9 which represents critical issues. Optional: this score could be configurable.
  • Where to display the warning
    • Option 1: As a after header UIX on all pages when the logged in user has Admin rights
    • Option 2: By introducing a new UIXP in the Admin UI (or revisiting the Admin UI home page which could be improved as it currently displays some icons, listing the same options as the vertical menu on the left).
  • We’ll need to ensure that advisories use some syntax when defining the affected XWiki version since we’ll need to parse this field. Example of returned value: "vulnerable_version_range": ">= 1.0.0, < 1.0.1"

WDYT?

Thanks

PS: FTR initially I was suggesting to include security disclosures as part of our What’s New feature, but after discussing with @MichaelHamann , I’ve agreed with him that displaying the list of advisories that applies to the current wiki is a better alternative.

Security warnings when using the latest XWiki version
Roadmap for XWiki 15.5
Dashboard for Security issues inside XWiki Standard
Source of CVEs for the security dashboard
#2

+1 with the general idea

Frankly I’m really not sure it would be needed or we’d really want it: even a security issue with a low score should be displayed IMO.

I’d be -1 for this option: it’s going to be a nightmare for Admins and they’ll start to find ways to systematically hide them. So for me it’s deserving the purpose.

-0 for the UIXP, I slightly prefer the idea of improving the UI home page.

I’d suggest an option 3: reusing the UIXP we have in the notification area (currently used for the license expiration for example) to display the number of advisories with a link, and having a new dedicated section in the Administration to display the details.

AFAIK we’re already using the best practices defined by Github for specifying the XWiki version, it’s even documented to use that on XWiki Security Policy - XWiki

#3

Sounds like a good idea to use the Alarm menu

If we list them all then we should also list their CVSS scores and use a LiveTable that can be filtered. You mentioned having an Admin UI section for Advisories. That sounds good and we could have the LT there.

#4

+1 for the general idea

I’m wondering if it’s really the right source. We are using GitHub more as an intermediary to publish CVE, but there are more generic references, like NIST (but seems there are many more from a quick google search). For example, with the NIST API you can use https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:xwiki:xwiki:12.6.6 to get all CVE affecting XWiki version 12.6.6.
That being said, I find a bit surprising that github seems to have reduced the package information we indicate in Arbitrary filesystem write access from velocity. · Advisory · xwiki/xwiki-commons · GitHub for example to just the product id “xwiki:xwiki” in the published CVE in NVD - CVE-2022-24897.

I think we need both a dashboard in the admin (the reference) and a warning in the header (that would lead to the admin dashboard if you want more details).

I don’t think this is needed if you use the right API (see the example I indicated above where all you have to do is indicate the specific version you want to check, and it will resolve all the CVEs for you, the GitHub API probably also have the same helper).

#5

Yes, I suggested the GitHub API as it seemed complete and nice but since there seems to exist a CVE REST API providing the same info, I agree that it’s a better source.

On the source topic, we might want to offer a REST API redirection on e.x.o if we want to make it easier for the XWiki installs at large (so that they don’t need to whitelist another domain - they’re likely to already have the e.x.o domain whitelisted). OTOH, this means more traffic to e.x.o which isn’t that great.

Thanks

#6

Yeah… I’m not a big fan of this. I think using an API which is a reasonable industry standard is good enough, it’s not like the instance was going to be completely broken if the API does not exist anymore, you just don’t get new advisories anymore (but honestly if you have an XWiki instance old enough for that, you probably have enough advisories already…).

#7

+1 for the general idea as well
-1 for Option 1
-1 for Option 2
+1 for Option 3 (for the same reasons as Simon)

+1

#8

My point was not about the URL being an API that would be broken in the future but rather that several companies only allow some whitelisted domains to be accessible by their apps (XWiki in this case).

But I mostly listed this to be complete as I also agree that they won’t see the advisories but OTOH no main feature of XWiki will broken. They’ll either need to whitelist https://services.nvd.nist.gov/* or use another way to find out what security issues are impacting them.

We’ll just need to handle this gracefully and provide a way to disable this feature.

#9

+1 for this.

#10

There’s just one issue I can see with using Alerts (XWiki.org) : we need the red bubble to increase the value to indicate that there are new alerts. ATM the alert bubble is only controlled by notifications I think. In any case, it makes sense to me that any UIX would be able to add/remove alert items to the bubble.

#11

@mflorea could probably confirm but AFAIR in case of outdated license there’s a visual hint with the background of the bell. We can probably do the same.

#12

Yes. When a font icon is used for the bell we simply change the text color. When an image is used we add some padding around the image and change the background color. See application-licensing/LicensesNotificationsUIX.xml at master · xwikisas/application-licensing · GitHub .

#13

I have started a design page for this feature.
Let me know if I’ve missed some use cases.
Thanks

#14

I’m wondering if it wouldn’t be interesting to collect the vulnerability data on XWiki.org as part of the extension repository if they shall be displayed for every installed extension. The data could then be downloaded by every XWiki instance as part of the extension metadata that is downloaded, anyways. That way, the vulnerability data could also be easily displayed on every extension page on XWiki.org. Further, it would be easier to improve this in the future, e.g., for changes how extension names are reflected in the CVE database (as this is primarily relevant for not-updated installations, we cannot count on the XWiki instance being updated).

#15

We discussed it a bit in a meeting with @tmortagne @vmassol and @mleduc.
There’s two dimensions about that questions.

First, we don’t store in extensions.xwiki.org all the actual things that are installed on a wiki. You could just decide to install a jar on your wiki, and it will be available in the installed extensions. So getting the vulnerabilities from exo won’t be enough, unless we want to mirror a CVE repository.

Now, for the extensions that are on exo we should be able in the future to provide information about known vulnerabilities. But that’s another work than the current one to display in XS the vulnerabilities of installed extensions.

1 Like
#16

Hi,
I’m dropping in a bit late on this topic, sorry about that.

I’ll second what @vmassol mentioned the issues on having another whitelisted domain. From my experience on deploying XWiki within corporate environments, there can be a lengthy process when it comes to allowing an XWiki server to talk to some other server on the internet. Sometimes, it’s not even possible, and we have to deploy the XWiki instance offline.

Today, we only have to whitelist the connection to the extension repository servers, namely :

As Active Installs goes through extensions.xwiki.org, we don’t need another whitelist entry.

For anyone deploying XWiki in these restricted environments, it could be a bit difficult to whitelist yet another domain, especially because this domain is not affiliated with the XWiki project. The mirroring option that @surli quickly mentioned would be the easiest, provided that we deploy it on one of the existing domains that we currently whitelist (for example https://extensions.xwiki.org/cve/).

There are to other points that could be interesting to consider when querying an external server :

  • The server who will receive the API calls to get the CVEs of an XWiki instance will know a lot about the attack surface of the XWiki instance. I’m not that much of a fan of sending information about the attack surface of XWiki instances to a website which is effectively owned by the US government.
  • We are effectively asking a lot of XWiki instances to do periodic queries to a service which is not hosted by the XWiki community. It may not be super nice to flood this service with queries. Having a proxy on extensions.xwiki.org that would also act as a cache would help on this part : if we see that we are getting too many queries, then we can act, both on the proxy side and also on the product side.
#17

To be clear about what I said here : today, we have XWiki instances that run without relying on any third-party service that is not managed by the XWiki community, with the exception of the YouTube video on the home page (which can be easily removed).

Adding a dependency on an external service run by a third party would break this self-sufficiency. On the contrary to the YouTube embed on the home page, it may not be very easy for a careless administrator to know that XWiki will communicate with a third-party server. One option to make it clear that XWiki will be communicating with a third party would be to add an extra step in the main wiki distribution wizard that asks for the admin consent.

#18

Note that when we discussed the feature we also decided that we would nicely handle any failure to communicate with the CVE server and display some nice message in the UI to explain it. Also, we need to be able to turn this feature off for admins who want to sandbox XWiki and/or run it without an internet connection.

#19

I agree with @caubin. In addition to what @caubin said, I think when running this proxy, we should make sure that under no circumstances we store the versions or identifiers of the queried packages (e.g., pass the data in the request body and make sure that request bodies aren’t logged).

Afaik there are currently no attempts in XWiki to hide version information, so if an installation is public, it should be easy to find out which version it is running and we probably also collect this information in active installs. Still, active installs pings can be disabled and we might make more attempts at hiding version information in the future.

#20

Active installs are anonymous.