Coordinated Disclosure Timeline
- 03/23/2020: Sent report to email@example.com
- 03/24/2020: Received acknowledgement
- 07/4/2020: Reported Uberspector bypass to Velocity security team
- 07/15/2020: Received acknowledgement
- 08/05/2020: Public PR containing the fix is submitted
- 02/26/2021: Fix gets merged
- Velocity Uberspector fails to prevent access to
- When Velocity templates are used in the context of a VelocityView an attacker that is able to modify Template contents may execute arbitrary Java code or run arbitrary system commands with the same privileges as the account running the Servlet container.
Apache Velocity 2.2
Improper BlockList verification
Velocity SecureUberspector prevents access to dangerous classes and packages by checking if any methods are invoked on the blocked classes. However Velocity fails to inspect the complete class hierarchy of the object where the method is invoked. This effectively means that if a method is called on an object of a given type that extends a class or implements an interface present in the BlockList, the invocation will not be blocked. As an example, the
java.lang.ClassLoader abstract class is present in the Secure Uberspector default BlockList, however, as an abstract class, it cannot be instantiated, so any calls on a ClassLoader instance will happen to be in a class extending
java.lang.ClassLoader which is not present in the BlockList.
For example, given the following template, the
ScriptEngineManager class will be successfully loaded:
Insufficient Sandbox Protection
Even though Velocity offers a great sandbox that prevents dangerous methods from being invoked, exposing Servlet related objects (such as the Servlet context) may introduce a variaty of objects which can be used to bypass the Velocity sandbox. Deep inspection of the exposed objects’ object graph allows an attacker to get access to objects that allow them to instantiate arbitrary Java objects. According to the documentation:
The HttpServletRequest, HttpSession, ServletContext, and their attributes are automatically available in your templates.
There are different ways to access the Servlet context including:
But if the application also exposes the context tool (which is the default), the Servlet context can also be accessed through:
On a Tomcat server the Servlet context will contain the
org.apache.tomcat.InstanceManager which enables an attacker to instantiate arbitrary objects. Note that the same class (regardless of its name) is available on other servlet containers such as Jetty and similar classes are available in other servers. For example JBoss/WildFly exposes
We can then try to run arbitrary Java code using a
In addition, on Spring applications a number of other Servlet context attributes may lead to remote code execution such as:
This issue may lead to
Remote Code Execution.
This issue was discovered and reported by GHSL team member @pwntester (Alvaro Munoz).
You can contact the GHSL team at
firstname.lastname@example.org, please include the
GHSL-2020-048 in any communication regarding this issue.