Headline
CVE-2023-29206: Privilege escalation via style sheet skin extensions with just edit rights
XWiki Commons are technical libraries common to several other top level XWiki projects. There was no check in the author of a JavaScript xobject or StyleSheet xobject added in a XWiki document, so until now it was possible for a user having only Edit Right to create such object and to craft a script allowing to perform some operations when executing by a user with appropriate rights. This has been patched in XWiki 14.9-rc-1 by only executing the script if the author of it has Script rights.
It is possible with a full CSS style sheet (but not a simple style-attribute) to exfiltrate any attribute value with one request per character with the help of a specially crafted server, see Better Exfiltration via HTML Injection. A particular technique detailed there using @import-directives allows to execute this attack in a single request by the victim. This can be used to exfiltrate the token used as CSRF protection of the current user. As XWiki allows basically everything with just a get request, the external server that has the CSRF token can then directly deliver (via a style sheet that is requested later via @import) a specially crafted URL as background image URL that changes, e.g., a user profile to grant more privileges or just saves a page with a groovy script. The attacker just requires edit privileges for creating a style sheet extension that is used on the current page.
This is basically the same as XWIKI-9119 just for style sheet extensions and with an attack scenario that is more complex as it requires a special external server that is reachable from the browser of the victim.
To protect against such attacks, we should consider either requiring programming rights (which might be a bit extreme) or at least prevent this attack by disallowing @import-directives unless the user has programming rights. There are also other attack vectors, though, and in particular if the attacker can modify the style sheet extension while the victim with programming rights is accessing them several times while a token is valid (currently as long as XWiki hasn’t been restarted) this is not going to prevent anything (see the linked article for details how the attack is executed).
Note that as long as XWIKI-10009 hasn’t been fixed and the attacker has script rights, no complex token extraction techniques must be used but the token can be obtained using ${services.csrf.getToken()} and directly used in the URL of a background image.
The affects version is tentative and taken from XWIKI-9119. I haven’t actually tried reproducing this in real as setting up the test server would require some time but I do not see why it shouldn’t be feasible given that the blog article linked above demonstrated the attack, the token is readily available in an attribute of the top-level HTML element and there is no special filtering of CSS as far as I’m aware.
I’m giving this a medium priority for now as the attack seems far more complex than other issues and I think we should first fix XWIKI-10009 as it seems far more obvious to exploit.
Related news
### Impact There was no check in the author of a JavaScript xobject or StyleSheet xobject added in a XWiki document, so until now it was possible for a user having only Edit Right to create such object and to craft a script allowing to perform some operations when executing by a user with appropriate rights. ### Patches This has been patched in XWiki 14.9-rc-1 by only executing the script if the author of it has Script right. ### Workarounds The only known workaround consists in applying [the following patch](https://github.com/xwiki/xwiki-platform/commit/fe65bc35d5672dd2505b7ac4ec42aec57d500fbb) and rebuilding and redeploying `xwiki-platform-skin-skinx`. ### References * https://jira.xwiki.org/browse/XWIKI-19514 * https://jira.xwiki.org/browse/XWIKI-9119 * https://jira.xwiki.org/browse/XWIKI-19583 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](http://jira.xwiki.org) * Email us at [Security ML](mailto:security@x...