See how xwiki compares to other vendors in security performance
Impact
It's possible for anyone to inject SQL using the parameter sort of the getdeleteddocuments.vm. It's injected as is as an ORDER BY value.
One can see the result of the injection with http://127.0.0.1:8080/xwiki/rest/liveData/sources/liveTable/entries?sourceParams.template=getdeleteddocuments.vm&sort=injected (this example does not work, but it shows that an HQL query was executed with the passed value which look nothing like an order by value, without any kind of sanitation).
Patches
This has been patched in 17.3.0-rc-1, 16.10.6.
Workarounds
There is no known workaround, other than upgrading XWiki.
References
https://jira.xwiki.org/browse/XWIKI-23093
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
The vulnerability was identifier by Aleksey Solovev from Positive Technologies.
Impact Any guest can perform arbitrary remote code execution through a request to SolrSearch. This impacts the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on an instance, without being logged in, go to <host>/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28"Hello%20from"%20%2B%20"%20search%20text%3A"%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20. If there is an output, and the title of the RSS feed contains Hello from search text:42, then the instance is vulnerable.
Patches This vulnerability has been patched in XWiki 15.10.11, 16.4.1 and 16.5.0RC1.
Workarounds This line in Main.SolrSearchMacros can be edited to match the rawResponse macro defined here with a content type of application/xml, instead of simply outputting the content of the feed.
References
https://jira.xwiki.org/browse/XWIKI-22149 https://github.com/xwiki/xwiki-platform/commit/67021db9b8ed26c2236a653269302a86bf01ef40
Attribution This vulnerability has been reported by John Kwak for Trend Micro's Zero Day Initiative.
Impact
By creating a conflict when another user with more rights is currently editing a page, it is possible to execute JavaScript snippets on the side of the other user, which compromises the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on a XWiki instance, a user with admin rights needs to edit a document without saving right away. Then, as another user without any other right than edit on the specific document, change the whole content to <script>alert('XSS')</script>. When the admin user then saves the document, a conflict popup appears. If they select "Fix each conflict individually" and see an alert displaying "XSS", then the instance is vulnerable.
Patches
This has been patched in XWiki 15.10.8 and 16.3.0RC1.
Workarounds
We're not aware of any workaround except upgrading.
References
https://jira.xwiki.org/browse/XWIKI-21626 https://github.com/xwiki/xwiki-platform/commit/821d43ec45e67d45a6735a0717b9b77fffc1cd9f
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
Impact A cross site request forgery vulnerability in the admin tool for executing shell commands on the server allows an attacker to execute arbitrary shell commands by tricking an admin into loading the URL with the shell command. A very simple possibility for an attack are comments. When the attacker can leave a comment on any page in the wiki it is sufficient to include an image with an URL like /xwiki/bin/view/Admin/RunShellCommand?command=touch%20/tmp/attacked in the comment. When an admin views the comment, the file /tmp/attacked will be created on the server. The output of the command is also vulnerable to XWiki syntax injection which offers a simple way to execute Groovy in the context of the XWiki installation and thus an even easier way to compromise the integrity and confidentiality of the whole XWiki installation.
Patches This has been patched by adding a form token check in version 4.5.1 of the admin tools.
Workarounds The patch can be applied manually to the affected wiki pages. Alternatively, the document Admin.RunShellCommand can also be deleted if the possibility to run shell commands isn't needed.
References https://jira.xwiki.org/browse/ADMINTOOL-91 https://github.com/xwiki-contrib/application-admintools/commit/03815c505c9f37006a0c56495e862dc549a39da8