In XWiki 15.5RC1 we released a first (MVP) version of the listing of security issues inside the wiki.
This listing contains only installed extensions (i.e., not core extension). And, it is conveniently empty on 15.5RC1 (at least we a standard distribution).
We’d now like to also list core extensions. And, this brings some additional complexity. If we don’t do anything special, the following kinds of extensions will be listed:
False-positive. For instance we depend on xstream which have known vulnerabilities. But, we know that we are not vulnerable.
Libraries provided by the servlet engines (e.g., jetty, tomcat). They are are accessible from the classpath, and can be used, but are not always in our control (except for the jetty demo archive, and the docker containers).
Having those extensions listed can convey a wrong message:
in the case of false-positive it’s adding noise, and might lead to admins being needlessly afraid (remember log4j)
in the case of core extension, admins might have the false impression that fixing the servlet related vulnerabilities is our responsibility (which is not always the case)
For both cases, I can see several options:
fully hide them
List them in separate Live Data (LD) in the administration page (with some specific explanations above the LDs)
My initial impression is that we should apply option 1 to false-positive, and option 2 for servlet libraries (as they can still be exploited from the wiki). But, I’d like to have your opinion.
Thanks
PS: We’ll also need to discuss where and how to define the list of false positives but that’s another topic.
How do you know which ones are false positives? Are you planning to maintain a manual white list?
EDIT: just saw the following, but I think we need to know how to do it before we can decide if we hide them or not.
PS: We’ll also need to discuss where and how to define the list of false positives but that’s another topic.
Yes +1 to hide false positives and +1 to show, in a different LD for servlet container deps (I’d put it on some advanced section, not visible by default since we’re not supposed to handle stuff outside of our control : servlet container, DB, java, OS, etc. It’s just a service we’re doing and that we can do to help or users).
Also, for servlet container deps, the LD will probably not have a “fix” column or if it has one, it’ll be something generic like “Upgrade your Servlet Container or contact the development team of it”.
Note: They’re not really in our control either actually, unless we’re don’t use the latest versions (but we’re supposed to use the latest versions).
That’s what we were heading to on some previous discussions with @tmortagne. iirc the idea was to make them accessible from an instance we control (most probably e.x.o).
We discussed the false-positive during the stakeholder meeting about that new feature and the outcome AFAIR was to provide a way for giving context to an admin about a vulnerability, but not to hide them: as @tmortagne emphasize during the meeting, some false-positive are only false-positive in the context of XS, but are real ones if a script user starts to do wrong stuff.
So I’d be -1 to fully and automatically hide them systematically.
Ideally we’d need an online DB of contextual information related to vulnerabilities we identified impacting core extensions. Now we could start with some embedded JSON file containing those info and we’ll provide the online stuff later.
We could provide two things probably:
tags
full text
the idea will be that tags could allow to filter them out from the LD while full text gives a complete information about the possible impacts.
environment vulnerabilities (what’s not in the WAR)
known vulnerabilities for which we have XWiki specific metadata (on extensions.xwiki.org I assume) suggesting that the impact is actually lower than what the CVE suggests (not impacting the features of XWiki Standard but could impact an extension, or even made completely uneffective by some hack/customization on XWiki side)
all the other vulnerabilities
Yeah, I’m not a huge fan of hiding them completely. Putting them in some special area, sure, but saying we are sure those vulnerabilities cannot be exploited in the instance is a lie, we just know (unless we made a mistake) the standard stuff don’t trigger these vulnerabilities.
I’m not -1 for a first version as it’s not like we had them right now anyway but deciding that there is no reason to list those, and we will never do would not make any sense.
While it sounds good at first sight, one problem is that you will only get explanations for vulnerabilities known when this version of XWiki was released, so the known list can quickly become close to useless.
It’s mainly a question of time frame. If we can also do the improvement on e.x.o during 15.6 roadmap, it’s perfect.
Otherwise, I’d be ok to use a static file in as a first step, and introduce the remote source later.
Be careful to handle the fact that a lot of XS usage inside companies don’t allow calling external URLs.
Same problem as getting info from the CVE database. Adding another URL makes the feature harder to configure/use. Ideally, both should be under the same URL from extensions.xwiki.org.
So, trying to summarize the discussion, we are converging toward a extension vulnerability admin page with three sections:
Installed extensions + core extensions which are not false positive and not from the servlet: the same LD as we have in 15.5RC1
False positive: all the extensions that are part of the false-positive source
Servlet: all the extensions that are provided by the servlet
Some remarks:
I’m not sure if we need to show the two last sections when the user is not advanced since the page is only accessible to admins
We can make the page slightly lighter by replacing the sections with tabs
I’m not really inspired regarding the name of the sections. This is important as they need to be easily understandable. I’ll propose something later when I have some ideas, but feel free to propose something in the meantime
an extension could be listed in the two first sections at the same time for different CVEs (e.g., extension X has CVE-a and CVE-b, and only CVE-b is a false-positive)
Well you say yourself that this page is only for admins, so I wouldn’t make any check for advanced or not and always display all info.
Something like “investigated vulnerabilities” for the second section? With a hint explaining exactly what it means.
And probably “Servlet engine vulnerabilities” for the final one?
Might be a bit too technical to even talk about Servlet, I feel we need something a little more generic expressing the fact that it’s related to the environment in which XWiki is running (and we might later add other things not related to the servlet at all like vulnerabilities in the Java version, etc.).
I said it’s possible to differentiate core extensions coming from the WAR and core extensions coming from elsewhere. It does not change what is a core extension.
@tmortagne I don’t understand what a core xwiki extension not located in the WAR means. What’s sure is that the servlet section should not list xwiki extensions. I just want to verify that you’re not suggesting that.
This whole thread is only about adding support for core extensions, and what you seem to be missing is that core extensions includes JARs which are not in the WAR, simply because the application server expose stuff of its own in the classloader accessible by XWiki.