In some cases, it's still possible to exploit the vulnerability that was fixed in the new version. When an XWiki installation is upgraded and that upgrade contains a fix for a bug in a document, just a new version of that document is added. XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. There are no known workarounds for this vulnerability.
A macro for displaying icons has been introduced to avoid injecting the raw wiki syntax of an icon set into another document. Icon themes now require script right and the code in the icon theme is executed within the context of the icon theme, preventing any rights escalation. This issue has been patched in XWiki 14.10.6 and 15.1. This impacts the confidentiality, integrity and availability of the whole XWiki instance. Further, the HTML output of the icon set is output as JSON in the icon picker and this JSON is interpreted as XWiki syntax, allowing again the injection of script macros into a document with programming right and thus allowing remote code execution. The XWiki syntax variant of the icon set is also used without any escaping in some documents, allowing to inject XWiki syntax including script macros into a document that might have programming right, for this the currently used icon theme needs to be edited. The () can be used to trigger the rendering of any icon set. There are different attack vectors, the simplest is the Velocity code in the icon set's HTML or XWiki syntax definition. By either creating a new or editing an existing document with an icon set, an attacker can inject XWiki syntax and Velocity code that is executed with programming rights and thus allows remote code execution. As a workaround an admin can manually disallow the tags by adding `form, input, select, textarea, button` to the configuration option `` in the `xwiki.properties` configuration file. This has been patched in XWiki 14.10.6 and 15.2RC1 by removing the central form-related tags from the list of allowed tags. The attacker would need to ensure that the edit form looks plausible, though, which can be non-trivial as without script right the attacker cannot display the regular content of the document. In the context of XWiki, this allows an attacker without script right to either create forms that can be used for phishing attacks or also in the context of a sheet, the attacker could add an input like `` that would allow remote code execution when it is submitted by an admin (the sheet is rendered as part of the edit form). The HTML sanitizer that is included in XWiki since version 14.6RC1 allowed form and input HTML tags. Xwiki commons is the common modules used by other XWiki top level projects.
0 kommentar(er)
