Impact

It's possible to exploit well known parameters in XWiki URLs to perform redirection to untrusted site. This vulnerability was partially fixed in the past for XWiki 12.10.7 and 13.3RC1 but there is still the possibility to force specific URLs to skip some checks, e.g. using URLs like http:example.com in the parameter would allow the redirect.

Patches

The issue has now been patched against all patterns that we know about for performing redirect. It also performs a real URI parsing that should protect in most cases. This has been patched in XWiki 14.10.4 and 15.0.

Workarounds

The only workaround is to upgrade XWiki.

References

JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20096 JIRA ticket about the improvment actually fixing the vulnerability: https://jira.xwiki.org/browse/XWIKI-20549 Previous advisory about open redirect: https://github.com/advisories/GHSA-jp55-vvmf-63mv

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 to Paulos Mesfin who originally reported the vulnerability.

Impact

XWiki supports scheduled jobs that contain Groovy scripts. Currently, the job checks the content author of the job for programming right. However, modifying or adding a job script to a document doesn't modify the content author. Together with a CSRF vulnerability in the job scheduler, this can be exploited for remote code execution by an attacker with edit right on the wiki.

For successful exploitation, the needs to have edit right on a document whose content has last been changed by a user with programming right. This could be the user profile for users created by admins. In this document, the attacker can create an object of class XWiki.SchedulerJobClass using the object editor. By setting job class to com.xpn.xwiki.plugin.scheduler.GroovyJob, cron expression to 0 0/5 ? and job script to services.logging.getLogger("foo").error("Job content executed"), the attacker can create a job. Now this job just needs to be triggered or scheduled. This can be achieved by embedding an image with the following XWiki syntax in any document that is visited by an admin: [[image:path:/xwiki/bin/view/Scheduler/?do=trigger&which=Attacker.Document]] where Attacker.Document is the document that has been prepared by the attacker. If the attack is successful, an error log entry with "Job content executed" will be produced.

Patches This vulnerability has been patched in XWiki 14.10.9 and 15.4RC1.

Workarounds There is no workaround.

References https://jira.xwiki.org/browse/XWIKI-20852 https://github.com/xwiki/xwiki-platform/commit/fcdcfed3fe2e8a3cad66ae0610795a2d58ab9662

Impact

Any registered user can use the content field of their user profile page to execute arbitrary scripts with programming rights, thus effectively performing rights escalation.

The problem is present since version 4.3M2 when AppWithinMinutes Application added support for the Content field, allowing any wiki page (including the user profile page) to use its content as an AWM Content field, which has a custom displayer that executes the content with the rights of the AppWithinMinutes.Content author, rather than the rights of the content author.

Patches

The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262 . The fix is in the content of the AppWithinMinutes.Content page that defines the custom displayer. By using the display script service to render the content we make sure that the proper author is used for access rights checks.

Workarounds

If you want to fix this problem on older versions of XWiki that have not been patched then you need to modify the content of AppWithinMinutes.Content page to use the display script service to render the content, like this:

- {{html}}$tdoc.getRenderedContent($tdoc.content, $tdoc.syntax.toIdString()).replace('{{', '{{'){{/html}} + {{html}}$services.display.content($tdoc, { + 'displayerHint': 'default' + }).replace('{{/html}}', '{{/html}}'){{/html}}

References

JIRA issue https://jira.xwiki.org/browse/XWIKI-19906 Fix https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262

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

This vulnerability has been found and reported by @michitux .

Impact

Any registered user can exploit a stored XSS through their user profile by setting the payload as the value of the time zone user preference. Even though the time zone is selected from a drop down (no free text value) it can still be set from JavaScript (using the browser developer tools) or by calling the save URL on the user profile with the right query string. Once the time zone is set it is displayed without escaping which means the payload gets executed for any user that visits the malicious user profile, allowing the attacker to steal information and even gain more access rights (escalation to programming rights).

The problem is present since version 4.1M2 when the time zone user preference was introduced.

Patches

The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/d11ca5d781f8a42a85bc98eb82306c1431e764d4 . The main fix is in the displayertimezone.vm precisely at this line:

$!escapetool.xml($value)

By escaping the displayed time zone value we make sure the attacker's payload is not executed.

Workarounds

If you want to fix this problem on older versions of XWiki that have not been patched then you need to edit displayertimezone.vm and escape the displayed time zone value here:

- $!value + $!escapetool.xml($value)

References

JIRA issue https://jira.xwiki.org/browse/XWIKI-20276 Fix https://github.com/xwiki/xwiki-platform/commit/d11ca5d781f8a42a85bc98eb82306c1431e764d4

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

This vulnerability has been found and reported by @michitux .

Impact The create action is vulnerable to a CSRF attack, allowing script and thus remote code execution when targeting a user with script/programming right, thus compromising the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, the XWiki syntax [[image:path:/xwiki/bin/create/Foo/WebHome?template=&parent=Main.WebHome&title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22)]] can be added to any place that supports XWiki syntax like a comment. When a user with script right views this image and a log message ERROR foo - Script executed! appears in the log, the XWiki installation is vulnerable.

Patches This has been patched in XWiki 14.10.9 and 15.4RC1 by requiring a CSRF token for the actual page creation.

Workarounds There are no known workarounds.

References https://jira.xwiki.org/browse/XWIKI-20849 https://github.com/xwiki/xwiki-platform/commit/4b20528808d0c311290b0d9ab2cfc44063380ef7