Hello all,
For XWiki 15.6RC1, we plan to list the security vulnerabilities of all the known extensions (only the installed extensions were listed in 15.5RC1).
And, this leads to some vulnerabilities being listed:
- com.thoughtworks.xstream:xstream/1.4.17
- GHSA-2q8x-2p7f-574v
- GHSA-3ccq-5vw3-2p6x
- GHSA-64xx-cq4q-mf44
- GHSA-6w62-hx7r-mw68
- GHSA-6wf9-jmg9-vxcc
- GHSA-8jrj-525p-826v
- GHSA-cxfm-5m4g-x7xp
- GHSA-f8cc-g7j8-xxpm
- GHSA-g5w6-mrj7-75h2
- GHSA-h7v4-7xg3-hxcc
- GHSA-hph2-m3g5-xxv4
- GHSA-j563-grx4-pjpv
- GHSA-j9h8-phrw-h4fh
- GHSA-p8pq-r894-fm8f
- GHSA-qrx8-8545-4wg2
- GHSA-rmr5-cpv2-vgjf
- GHSA-xw4p-crpj-vjx2
- org.jdom:jdom/1.1.3: GHSA-2363-cqg2-863c
- net.sourceforge.htmlcleaner:htmlcleaner/2.24: GHSA-jv4x-j47q-6qvp
- org.eclipse.jetty:jetty-xml/10.0.15: GHSA-58qw-p7qm-5rvh
From what we know, those dependencies are not dangerous when it comes to the code we control (xwiki-commons, xwiki-rendering, xwiki-platform, and some contrib extensions). And, we want to present them as such to admins, to avoid some irrelevant anxiety Of course we can’t draw the same conclusions for code we don’t control.
Naming
I’m currently using ignore or “false positive” to designate vulnerabilities we are aware of and consider as not dangerous.
I propose to use “analyzed extensions” as the default vocabulary (both for our source code and for UIs labels).
I’m currently using “Servlet” for the extensions that are not provided by the packaged XWiki instance or an installed extension.
Admin Experience
Some screenshots of my current PoC, to give you an idea of where I’m currently heading.
The extension vulnerabilities tab lists all extensions with at least one extension that is not marked as “analyzed”.
The ignored vulnerability (which should be renamed “analyzed vulnerabilities”) tab lists all extensions with only “analyzed” vulnerabilities.
The servlet vulnerabilities tab lists all extensions provided by the servlet engine, regardless of their “analyzed” status.
Note that “analyzed” vulnerabilities are visually distinguished by their smaller font size and the button on their right, allowing to access a modal screen providing the details of the analysis (fourth screenshot above).
Maintainer Experience
Maintainers are in charge of keeping up to date the analysis status of the vulnerabilities.
For now, I’m planning to expose the list of analyzed vulnerabilities using a json object (see below for an example), provided by a page in extension.xwiki.org (e.g., https://extensions.xwiki.org/xwiki/bin/view/Extension/Extension/Security/Code/AnalyzedVulnerabilities/), which would be only editable by members of XWikiCommittersGroup
.
Currently, extensions are considered as:
- vulnerable if no analyzed vulnerability can be found for at least one of its known vulnerabilities
- “analyzed” otherwise (i.e., all its known vulnerabilities can be found)
Some remarks:
- We’ll need to commit to maintain this list (and be reactive), this also mean being able to provide clear explanations of each analysis. This can imo be time consuming, and we’ll probably need to work as a group to make the first explanations clear to have good examples to follow in the future, and to give a first good impression to the first users of the feature.
- The current design currently does not take into account the case where some extensions identify a vulnerability as impacting it while it was marked as analyzed by some other extensions. We can consider a few options:
- remove the entry and all the explanations in the analyzed vulnerabilities source, but in this case all the existing explanations are lost
- provide a way to explicit that an given extension is vulnerable, but this means providing the ability to bind an analyzed vulnerability to a given extension (including the version range where it is impacted)
- ask the vulnerable extension to create an adhoc security advisory, which would itself reference the “analyzed” vulnerability, and explaining how to exploit the vulnerability in its own context
- As for the source of vulnerabilities, admins will be able to point to their own source of analyzed vulnerabilities. Do we want to provide a way to allow maintainers to “inherit” from the main source of analyzed vulnerabilities (i.e., the one from e.x.o)?
Note: in a first step I propose to maintain the source of analyzed vulnerabilities as a static json (possibly with some velocity to avoid some explanations duplication), and to provide a way to declare analyzed vulnerabilities as XObjects on e.x.o in a second time
{
"analyzedVulnerabilitiesMap": {
"GHSA-2q8x-2p7f-574v": [
{
"source": "xwiki-platform",
"explanation": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus non pellentesque sem. Maecenas ultricies, nisi quis efficitur consectetur, libero enim blandit justo, at auctor nisi arcu congue odio. "
},
{
"source": "some-extension",
"explanation": "ivamus eget condimentum elit, in blandit turpis. Nullam suscipit eros vitae justo suscipit aliquam. Curabitur at nibh id elit eleifend condimentum eu a urna. Vivamus vel molestie nunc. Suspendisse porta porta quam, vel pulvinar magna vulputate a. In porta tincidunt dui. Cras tortor ante, interdum eget enim quis, posuere varius ligula."
}
],
"GHSA-3ccq-5vw3-2p6x": [
{
"source": "xwiki-platform",
"explanation": "ivamus eget condimentum elit, in blandit turpis. Nullam suscipit eros vitae justo suscipit aliquam. Curabitur at nibh id elit eleifend condimentum eu a urna. Vivamus vel molestie nunc. Suspendisse porta porta quam, vel pulvinar magna vulputate a. In porta tincidunt dui. Cras tortor ante, interdum eget enim quis, posuere varius ligula."
}
]
}
Let me know what you think.
Thanks,
Manuel