Impact
In an instance which is using the XWiki Jetty package (XJetty), a context is exposed to statically access any file located in the webapp/ folder.
It allows accessing files which might contains credentials, like http://myhots/webapps/xwiki/WEB-INF/xwiki.cfg, http://myhots/webapps/xwiki/WEB-INF/xwiki.properties or http://myhots/webapps/xwiki/WEB-INF/hibernate.cfg.xml.
Patches
This has been patched in 16.10.11, 17.4.4, 17.7.0.
Workarounds
The workaround is to modify the startxwiki.sh script following https://github.com/xwiki/xwiki-platform/compare/8b68d8a70b43f25391b3ee48477d7eb71b95cf4b...99a04a0e2143583f5154a43e02174155da7e8e10.
For more information
If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List
Attribution
Vulnerability reported by Joseph Huber.
Impact XWiki's REST API doesn't enforce any limits for the number of items that can be requested in a single request at the moment. Depending on the number of pages in the wiki and the memory configuration, this can lead to slowness and unavailability of the wiki. As an example, the /rest/wikis/xwiki/spaces resource returns all spaces on the wiki by default, which are basically all pages.
Patches XWiki 17.7.0RC1, 17.4.4 and 16.10.11 introduce a configurable limit, limiting responses to 1000 items by default. Requesting larger limits leads to an error now.
Workarounds We're not aware of any workaround, except denying access to the affected REST resources in a proxy in front of XWiki.
Impact An improperly protected scripting API allows any user with script right to bypass the sandboxing of the Velocity scripting API and execute, e.g., arbitrary Python scripts, allowing full access to the XWiki instance and thereby compromising the confidentiality, integrity and availability of the whole instance. Note that script right already constitutes a high level of access that we don't recommend giving to untrusted users.
Patches The vulnerability has been patched in XWiki 17.4.8 and 17.10.1 by requiring programming right to access the affected scripting API.
Workarounds We're not aware of any workarounds except for being careful whom you grant script right.
Attribution We thank Youssef Azefzaf for discovering and reporting this vulnerability.
Impact REST API endpoints like /xwiki/rest/wikis/xwiki/spaces/AnnotationCode/pages/AnnotationConfig/objects/AnnotationCode.AnnotationConfig/0/properties list all available pages as part of the metadata for database list properties, which can exhaust available resources on large wikis.
Patches This problem has been patched by applying the configured query limit also to the available values for database list properties in XWiki 16.10.16, 17.4.8 and 17.10.1.
Workarounds We're not aware of any workarounds apart from upgrading the affected modules.
Impact A reflected XSS vulnerability in XWiki allows an attacker to send a victim to a URL with a deletion confirmation message on which the attacker-supplied script is executed when the victim clicks the "No" button. When the victim has admin or programming right, this allows the attacker to execute basically arbitrary actions on the XWiki installation including remote code execution.
Patches This vulnerability has been patched in XWiki 16.10.10, 17.4.2 and 17.5.0 by using the affected URL parameter only in the intended context.
Workarounds The patch can be manually applied to the templates that are present in the WAR. A restart of XWiki is needed for the changes to be applied.
Impact A reflected cross-site scripting vulnerability (XSS) in the compare view between revisions of a page allows executing JavaScript code in the user's browser. If the current user is an admin, this can not only affect the current user but also the confidentiality, integrity and availability of the whole XWiki instance.
Patches The problem has been patched by properly escaping the URL parameters.
Workarounds The patch can be applied manually to templates/changesdoc.vm in the deployed WAR.
Attribution
XWiki thanks Mike Cole @mikecole-mg for discovering and reporting this vulnerability.
Impact
It's possible using comments to inject CSS that would transform the full wiki in a link area leading to a malicious page. All versions of XWiki are impacted by this kind of attack.
Patches
The problem has been patched not by preventing injecting CSS in comments, which is currently a feature of XWiki, but by requiring confirmation from users when driving them to untrusted domains after clicking on a link, thus preventing any click-jacking attack. This security measure has been put in place in XWiki 17.9.0, 17.4.6, 16.10.13.
Workarounds
There's no out-of-the-box workaround, but it should be possible to partly reuse the javascript code provided for the security measure in a JSX object inside the wiki, to request the same kind of confirmation.
References JIRA ticket: https://jira.xwiki.org/browse/XWIKI-23433 Documentation of the new security measure: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/17.9.0RC1/Entry006/ Commit for the security fix: https://github.com/xwiki/xwiki-platform/commit/29cb81f3a5387cf822d7e7534bdd63903275f86b
For more information
If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List
Attribution
Thanks Tomas Keech (Sentrium Security Ltd) for reporting this vulnerability.