Listing security issues of core extensions on the wiki

[mleduc]

Hello all,

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:

1. fully hide them
2. 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.

[vmassol]

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”.

@mleduc

(except for the jetty demo archive, and the docker containers).

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).

Thanks

[mleduc]

@vmassol

Are you planning to maintain a manual white list?

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).

[surli]

@mleduc

For both cases, I can see several options:

1. fully hide them
2. 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.

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:

1. tags
2. 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.

[tmortagne]

+1 in general to separate:

• 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

@surli

some false-positive are only false-positive in the context of XS

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.

@surli

Now we could start with some embedded JSON file containing those info and we’ll provide the online stuff later.

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.

[mleduc]

@tmortagne

@surli

Now we could start with some embedded JSON file containing those info and we’ll provide the online stuff later.

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.

[surli]

@tmortagne

@surli

Now we could start with some embedded JSON file containing those info and we’ll provide the online stuff later.

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.

Indeed.

@mleduc

Otherwise, I’d be ok to use a static file in as a first step, and introduce the remote source later.

An easy move would be to have a document in exo that returns that JSON statically for now.

[vmassol]

@surli

An easy move would be to have a document in exo that returns that JSON statically for now.

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.

[mleduc]

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)

@surli

An easy move would be to have a document in exo that returns that JSON statically for now.

Indeed, good idea!

[vmassol]

@mleduc

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

Quick note on this: admins are not advanced users by default. Probably lots of them (especially in largish companies) are not advanced users.

[tmortagne]

@mleduc

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)

Actually, I don’t think so, as for me the filtering is:

• servlet section: only core extension, which file is not located in the WAR
• false positive section: extensions (core/installed) which contains only false positive vulnerabilities
• everything else

[vmassol]

@tmortagne

servlet section: only core extension, which file is not located in the WAR

not sure I understand. Core extensions (xwiki) != servlet dependencies

[surli]

@mleduc

• 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

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.

@mleduc

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

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?

[tmortagne]

@vmassol

not sure I understand. Core extensions (xwiki) != servlet dependencies

As discussed yesterday in the chat, core extensions are all extensions that were found in the classloader.

[tmortagne]

@surli

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.).

[vmassol]

@tmortagne

As discussed yesterday in the chat, core extensions are all extensions that were found in the classloader.

yes but you said that you could differentiate core xwiki extensions from servlet dependencies.

[vmassol]

@tmortagne

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.).

It’s ok to list everything from the environment in the same list, but it won’t help much the infra admins unless we add a column explaining the system in cause. Note that we can get the servlet container name and version and it would be good to display it (see xwiki-platform/xwiki-platform-core/xwiki-platform-activeinstalls2/xwiki-platform-activeinstalls2-api/src/main/java/org/xwiki/activeinstalls2/internal/data/ServletContainerPingDataProvider.java at bb6451209ff3ec2694e48b77e115ec651c45e8b6 · xwiki/xwiki-platform · GitHub).

[tmortagne]

@vmassol

yes but you said that you could differentiate core xwiki extensions from servlet dependencies.

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.

[vmassol]

@tmortagne

servlet section: only core extension, which file is not located in the WAR

@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.

[tmortagne]

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.