CVE-2023-37895: A Critical Remote Code Execution in Apache Jackrabbit

A critical security vulnerability, identified as CVE-2023-37895, has been discovered in Apache Jackrabbit, an open-source content repository for the Java platform. The vulnerability could allow an attacker to remotely execute code on a vulnerable system by exploiting a Java object deserialization issue in the RMI implementation.

Apache Jackrabbit, an implementation of the Content Repository for Java Technology API (JCR), has established itself as a comprehensive platform for managing content in a repository. It boasts robust capabilities like structured and unstructured content support, full-text search, versioning, transactions, and observation, and enjoys widespread application in web content management systems, document management systems, and enterprise content management systems.

The CVE-2023-37895 vulnerability lies in the potential for remote code execution (RCE) through the exploitation of the Remote Method Invocation (RMI) interface in Jackrabbit. This vulnerability poses a significant risk as it can allow an attacker to execute arbitrary code remotely, effectively compromising the system. This security issue, categorized as ‘critical,’ affects the Apache Jackrabbit Webapp and Standalone versions ranging from 1.0.0 to 2.21.18.

The origin of this critical security flaw is rooted in a Java object deserialization issue present in all platforms of Jackrabbit webapp and standalone versions up to 2.20.10 and 2.21.17. Exploitation involves the component “commons-beanutils,” which contains a class vulnerable to remote code execution via RMI.

The immediate remedial measure recommended for Jackrabbit users is an immediate update to either versions 2.20.11 or 2.21.18. Notably, older stable branches (1.0.x to 2.18.x) have already been marked End of Life (EOL) and are not slated for further updates.

However, even in the absence of exploitable code within Jackrabbit itself, the simple existence of RMI support can expose potential vulnerabilities. Additional components on the server could precipitate the same problem, emphasizing the need to disable RMI access completely. Furthermore, discussions are underway to consider the deprecation of 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 user’s 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:

<servlet>

            <servlet-name>RMI</servlet-name>

            <servlet-class>org.apache.jackrabbit.servlet.remote.RemoteBindingServlet</servlet-class>

        </servlet>



        <servlet-mapping>

            <servlet-name>RMI</servlet-name>

            <url-pattern>/rmi</url-pattern>

        </servlet-mapping>

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.