Impact
Anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance.
The easiest way to reproduce this is to edit any document with the object editor and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in Category" to "other", set scope to "Wiki and all spaces" and "Heading" to {{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"); println("Hello from Groovy!"){{/groovy}}{{/async}}. Click "Save". Open <xwiki-host>/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet&viewer=content&editor=globaladmin§ion=other where <xwiki-host> is the URL of your XWiki installation. If this displays just "Hello from Groovy!" in a heading and generates an error message with content "Attack from Heading succeeded!" in XWiki's log, the attack succeeded. Similar attacks are also possible by creating this kind of object on a document with a specially crafted name, see the referenced Jira issues for more reproduction steps.
Patches This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1
Workarounds
It is possible to manually apply the fixes for the vulnerability by editing two pages in the wiki. This patch needs to be applied to the page XWiki.ConfigurableClassMacros. Further, the following patches need to be applied to the page XWiki.ConfigurableClass:
https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6
Note that also the page XWiki.ConfigurableClass needs to be changed to xwiki/2.1 syntax for the escaping to work properly but the security vulnerability is fixed also without changing the syntax.
References
https://github.com/xwiki/xwiki-platform/commit/bd82be936c21b65dee367d558e3050b9b6995713 https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7 https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6 https://jira.xwiki.org/browse/XWIKI-21122 https://jira.xwiki.org/browse/XWIKI-21121 https://jira.xwiki.org/browse/XWIKI-21194
Impact There is a reflected XSS or also direct remote code execution vulnerability in the code for displaying configurable admin sections. The code that can be passed through a URL parameter is only executed when the user who is visiting the crafted URL has edit right on at least one configuration section. While any user of the wiki could easily create such a section, in this case it is much more convenient to exploit GHSA-qj86-p74r-7wp5 which is why this attack scenario won't be further considered in the following. In contrast to GHSA-qj86-p74r-7wp5, this vulnerability doesn't require the attacker to have an account or any access on the wiki. It is sufficient to trick any admin user of the XWiki installation to visit the crafted URL. Alternatively, the URL can also be embedded as image source of an image in any content of the wiki like a comment that could be left by an anonymous user. This vulnerability allows full remote code execution with programming rights and thus impacts the confidentiality, integrity and availability of the whole XWiki installation.
Patches
This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1
Workarounds
The patch can be manually applied to the document XWiki.ConfigurableClass.
References
https://github.com/xwiki/xwiki-platform/commit/5e14c8d08fd0c5b619833d35090b470aa4cb52b0 https://jira.xwiki.org/browse/XWIKI-21167
Impact Any user with script rights can perform arbitrary remote code execution by adding instances of XWiki.ConfigurableClass to any page. This compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on a instance, as a user with script rights, edit your user profile and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in category" to other, "Scope" to Wiki and all spaces and "Heading" to: #set($codeToExecute = 'Test') #set($codeToExecuteResult = '{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"){{/groovy}}{{/async}}') Save the page and view it, then add ?sheet=XWiki.AdminSheet&viewer=content§ion=other to the URL. If the logs contain "attacker - Attack from Heading succeeded!", then the instance is vulnerable.
Patches This has been patched in XWiki 15.10.9 and 16.3.0.
Workarounds We're not aware of any workaround except upgrading.
References https://jira.xwiki.org/browse/XWIKI-21207 https://github.com/xwiki/xwiki-platform/commit/8493435ff9606905a2d913607d6c79862d0c168d
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
The XWiki Platform Index UI is an Index of all pages, attachments, orphans and deleted pages and attachments for XWiki Platform, a generic wiki platform. Prior to versions 13.10.6 and 14.3, it's possible to store JavaScript which will be executed by anyone viewing the deleted attachments index with an attachment containing javascript in its name. This issue has been patched in XWiki 13.10.6 and 14.3. As a workaround, modify fix the vulnerability by editing the wiki page XWiki.DeletedAttachments with the object editor, open the JavaScriptExtension object and apply on the content the changes that can be found on the fix commit.
Impact
It's possible to execute javascript with the right of any user by leading him to a special URL on the wiki targeting a page which contains an attachment.
To reproduce: add an attachment to a page (for example, your user profile) add ?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E to the page view URL as in https://myhost/xwiki/bin/view/XWiki/MyUser?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E
Patches
This has been patched in XWiki 15.0-rc-1, 14.10.4 and 14.4.8.
Workarounds
The easiest is to edit file <xwiki app>/templates/importinline.vm and apply the modification described on https://github.com/xwiki/xwiki-platform/commit/28905f7f518cc6f21ea61fe37e9e1ed97ef36f01
References
https://jira.xwiki.org/browse/XWIKI-20340 https://app.intigriti.com/company/submissions/e95a7ad5-7029-4627-abf0-3e3e3ea0b4ce/XWIKI-E93DFEYK
Attribution
This vulnerability has been reported on Intigriti by René de Sain @renniepak.
APIs to evaluate content with Velocity is a package for APIs to evaluate content with Velocity. Starting with version 2.3 and prior to 12.6.7, 12.10.3, and 13.0, the velocity scripts are not properly sandboxed against using the Java File API to perform read or write operations on the filesystem. Writing an attacking script in Velocity requires the Script rights in XWiki so not all users can use it, and it also requires finding an XWiki API which returns a File. The problem has been patched in versions 12.6.7, 12.10.3, and 13.0. There is no easy workaround for fixing this vulnerability other than upgrading and being careful when giving Script rights.
XWiki Platform is a generic wiki platform. Prior to versions 13.10.5 and 14.3, it is possible to perform a Cross-Site Request Forgery (CSRF) attack for adding or removing tags on XWiki pages. The problem has been patched in XWiki 13.10.5 and 14.3. As a workaround, one may locally modify the documentTags.vm template in one's filesystem, to apply the changes exposed there.