Security warnings when using the latest XWiki version

Development
,
#1

Hi,

Threads related to this topic :

Recently, we introduced a Security Dashboard in XWiki instances. This dashboard is helpful for displaying the list of known security vulnerabilities coming from XWiki or one of its dependencies.

However, I have a little bit of a concern when it comes to the adoption of XWiki. Hear me out :

Today, I downloaded XWiki 15.8 with Jetty/HSQLDB. 15.8 was released yesterday, so it’s supposed to be the most up-to-date version of XWiki. Within 5 mins after starting the XWiki instance, an error message appeared in the notifications menu, indicating that some security vulnerabilities were identified in this XWiki version.

While there’s a clear added benefit of providing security insights on the XWiki instance, I fear that the way we implemented the security dashboard for now has a serious impact on how new users get a first impression of XWiki. If I put myself in the shoes of a new user, just trying things out, the following points could make me just want to stop using XWiki, and not continue my tests :

  1. I can be confused by this error message because the version I installed is actually the latest one. While it is true that many software are released with existing vulnerabilities, it’s not exactly what first-time users expect to see in their first 5 mins of using the software.
  2. When going in the security dashboard, I see that vulnerabilities are coming from provided extensions, and that currently, no fix exist for resolving them. Why should these be listed if we don’t provide any option to fix them ?
  3. I cannot discard the alert about security vulnerabilities without disabling the security scans completely. So basically, if I choose to stay in this situation and not disable the scans, my notifications bell will be permanently red, with a red notification message at the top of the notifications.

A 4th point, which requires a bit more digging, is that the three “extensions vulnerabilities” reported do not seem to be part of the roadmap for the upcoming version. As such, a new user may have trouble understanding :

  • The real impact of the security vulnerabilities that are presented in the administration
  • When these vulnerabilities are expected to be fixed

My feeling is that we should look into how to answer the 3 points listed above before we go in LTS. What do you think about them ? Do we agree that the points above are legitimate ?

In my case, the vulnerabilities that were reported are the following :

For extension vulnerabilities :

For environment vulnerabilities :

I don’t know what would be the behavior if I did not have any extension vulnerabilities, but still some environment vulnerabilities.

Thanks,
Clément

1 Like
#2

It’s clear to me that we shouldn’t release a version of XWiki that has known security issues.

AFAIR we have an automated test for this though (ping @mleduc to verify this).

I agree.

What is a provided extension? Do you mean it’s an extension provided by XS and not an extension you’ve installed?

You cannot just accept this notification?

Agreed.

This one was fixed for 15.9RC1. We wanted to fix it for 15.8 but we didn’t get the time before the release. This is not an XWiki security issue per see (it’s an environmental one). My take is that it depends on how you installed XWiki. If you’ve installed the Demo packaging with jetty/hsqldb then it’s our fault and we shouldn’t release if there are security issues or if we do, it should be indicated in the release notes and explained why we couldn’t fix it. Probably the same if you installed XWiki with the DEB packaging. However, if you installed the WAR and manually installed the servlet container then it’s another matter ofc.

We need to review the automated test that verifies that there’s no security issue and make sure that environment issues also prevent releasing XWiki.

Do these come from XS or from some extensions you installed? If they come from XS then there’s a problem with the automated test I’m referring to and we need to fix it ASAP (cc @mleduc ).

Thanks for raising this @caubin ! I’m also very surprised to hear that there are security issues with a version of XS that we released.

#3

We don’t yet.
Also, security vulnerabilities are issued regularly, what we check at release time can change overtime.

For instance, org.xerial.snappy:snappy-java:1.1.10.4 fixing the 1.1.10.3 was released 2 days ago.

The notification yes, but currently not the red notification bell.

The security issue that is currently triggering the red bell is currently analyzed but is likely to be a false positive.

#4

ok then it’s urgent that we add it ASAP. This is critical IMO.

Ofc but releasing an XWiki version with a known security issue that we could fix is a no go for me. And if we cannot fix it, it needs to go in the RN in red, with an explanation.

BTW are the analysis/explanations taken from xwiki.org so that existing XS instance have up to date information?

#5

Note that idk what form it should take (haven’t though much) but:

  • we need to know as soon as a new security issues is found so that we have time to work on it before the next release
  • we need to be sure that we cannot release with some security issue not fixed or we decide that we cannot fix and put the info in the release notes.
#6

ok, this is Loading...

yes, from http://extensions.xwiki.org

#7

That’s the point of the planned integration test. But we need to finish implement it.

#8

TODOs (IMO):

  • Add the check in the build/release process, the idea is to make sure we don’t release without having analyzed/fixed the security issues
  • Display explained vulnerabilities differently than others (and possibly only to advanced users).
  • (to be discussed) Only send notifications for actionable vulnerabilities to Admins. Possibly have an opt-in config for admins who want to be warned about the others too. Similarly when displaying the vulnerabilities, have an advanced section to see the vulnerabilities that are “complex”, ie for which there’s no action the user can take.
  • Review the analysis message we display and find a process to ensure they’re good enough and decide the process to update them. Right now for ex “While jdom is part of our dependency, SAXBuilder stays unused.” is not very accurate. Something like the following would be better: “[…] part of XWiki dependencies, the SAXBuilder class is not used by XWiki Standard. However it’s possible that installed extensions use it and it’s up to the Admin of the wiki to verify this (as we cannot verify this automatically).”. Ofc we should upgrade the dependency if we can, that’s always a better solution.
#9

I agree with @caubin that this looks scary if you don’t read all texts and understand them.

So, my take on this is that we need to look at the objective of this feature and try to explain as much as possible to an Admin what they should do about it and how should they feel about things on which they can’t do anything - also, what they should tell their boss.

The topic of this security check has 2 dimensions:

  • information about the state of the wiki,
  • actions that need to be taken / can be taken.

While it’s not clear from the initial proposal, apparently we want to answer both dimensions with this feature.
To me, the information aspect could be left aside, it may hurt more than benefit to push the information under the nose of the admins, as it would scare more than inform, especially as they cannot do anything about it. I’m not saying to not make the information available, I’m saying to maybe not display it by default from the administration of the wiki, visible by all admins (which may or may not be technical).
If we’re not ready to drop the informative stuff, it should definitely be toned down a bunch compared to what @caubin noticed in 15.8.

Thus:

  • items on which the Admin can act need to be displayed clearly and separated in the administration
    • these should be the only ones on which there needs to be a red, blocking, severe notification.
    • it would be nice that the notification is dismissable if the admin decides to take responsibility for it :wink:
  • items of which “we know”, that are vulnerabilities that could be exploited but are not by default - such as 2 of the the extension vulnerabilities @caubin should definitely not be presented in the same table as the actionable items.
  • we really need to explain properly this aspect of "an issue can be discovered after the release of your XWiki version and the XWiki team is working on analysing / classifying / fixing this asap, “stay calm and keep using your wiki while a new version is being developed”. The same rule about whether the admin can do any action or not needs to apply to these as well.

Hope this helps,
Anca

#10

there’s another thing that I just realized, while discussing live with @caubin:

  • for all the security problems in this category, AFAIU, in the current implementation, the admin of the wiki and the XWiki team will find out about the security problem at the same moment - when the CVE is published by the third party dependency. I don’t really know whether the value of this is as high as the alert (and confusion) it may create - the admin of the wiki will need to understand this, that a security issue cannot be fixed immediately, that a new version takes time to release, etc. Also, they may not understand what’s the point of showing it to them in their wiki.

Users may not be used to such transparency (as the one we’re building with the informative dimension of this feature), and if we decide to keep it, we’ll need to be very clear about it means, in terms that are easy to understand for anyone, regardless of their technical level, that would increase the user’s confidence rather than make them more worried. We need to manage to convey the information that “there will always be issues or risks, all we’re doing here is make sure to catch these issues early, which is better than pretend they don’t exist”). The problem here is that it takes an experienced professional to know that a software will always have bugs, even if they’re not known yet; the only time when there are 0 bugs is when there hasn’t been enough testing… I’m not convinced that most users of software have favorable mental habits on this topic (so we’d be part of building these habits), and even if they do, there may be biases and emotions involved when talking about “security problems”…

The more I think about it, the more I think that this feature should be a channel for actions - as other software do when they tell about an issue only when they also have a solution for it (e.g. gitlab) - rather than an informative thing.

Thanks,
Anca

Make the security scan dashboard deactivated by default