Java object deserialization issue in Jackrabbit webapp/standalone on all platforms allows attacker to remotely execute code via RMIVersions up to (including) 2.20.10 (stable branch) and 2.21.17 (unstable branch) use the component commons-beanutils, which contains a class that can be used for remote code execution over RMI.
Users are advised to immediately update to versions 2.20.11 or 2.21.18. Note that earlier stable branches (1.0.x .. 2.18.x) have been EOLd already and do not receive updates anymore.
In general, RMI support can expose vulnerabilities by the mere presence of an exploitable class on the classpath. Even if Jackrabbit itself does not contain any code known to be exploitable anymore, adding other components to your server can expose the same type of problem. We therefore recommend to disable RMI access altogether (see further below), and will discuss deprecating RMI support in future Jackrabbit releases.
How to check whether RMI support is enabledRMI support can be over an RMI-specific TCP port, and over an HTTP binding. Both are by default enabled in Jackrabbit webapp/standalone.
The native RMI protocol by default uses port 1099. To check whether it is enabled, tools like netstat can be used to check.
RMI-over-HTTP in Jackrabbit by default uses the path /rmi. So when running standalone on port 8080, check whether an HTTP GET request on localhost:8080/rmi returns 404 (not enabled) or 200 (enabled). Note that the HTTP path may be different when the webapp is deployed in a container as non-root context, in which case the prefix is under the users control.
Turning off RMIFind web.xml (either in JAR/WAR file or in unpacked web application folder), and remove the declaration and the mapping definition for the RemoteBindingServlet:
RMI org.apache.jackrabbit.servlet.remote.RemoteBindingServlet
RMI /rmi
Find the bootstrap.properties file (in $REPOSITORY_HOME), and set
rmi.enabled=false
and also remove
rmi.host rmi.port rmi.url-pattern
If there is no file named bootstrap.properties in $REPOSITORY_HOME, it is located somewhere in the classpath. In this case, place a copy in $REPOSITORY_HOME and modify it as explained.
The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Jackrabbit | Apache | 1.0.0 (including) | 2.20.11 (excluding) |
| Jackrabbit | Apache | 2.21.0 (including) | 2.21.18 (excluding) |
| Jackrabbit | Ubuntu | bionic | * |
| Jackrabbit | Ubuntu | lunar | * |
| Jackrabbit | Ubuntu | mantic | * |
| Jackrabbit | Ubuntu | trusty | * |
| Jackrabbit | Ubuntu | upstream | * |
| Jackrabbit | Ubuntu | xenial | * |
It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security – which is a dangerous security assumption. Data that is untrusted can not be trusted to be well-formed. When developers place no restrictions on “gadget chains,” or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.