Apache Jackrabbit up to 2.20.10/2.21.17 deserialization

Summaryinfo

A vulnerability categorized as critical has been discovered in Apache Jackrabbit up to 2.20.10/2.21.17. This issue affects some unknown processing. The manipulation results in deserialization. This vulnerability is cataloged as CVE-2023-37895. The attack may be launched remotely. There is no exploit available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability classified as critical has been found in Apache Jackrabbit up to 2.20.10/2.21.17. Affected is an unknown functionality. The manipulation with an unknown input leads to a deserialization vulnerability. CWE is classifying the issue as CWE-502. The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid. This is going to have an impact on confidentiality, integrity, and availability. CVE summarizes:

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 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:                     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 weakness was shared 07/26/2023. The advisory is shared for download at openwall.com. This vulnerability is traded as CVE-2023-37895 since 07/10/2023. There are neither technical details nor an exploit publicly available.

Upgrading eliminates this vulnerability.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• Apache

Name

• Jackrabbit

Version

• 2.20.0
• 2.20.1
• 2.20.2
• 2.20.3
• 2.20.4
• 2.20.5
• 2.20.6
• 2.20.7
• 2.20.8
• 2.20.9
• 2.20.10
• 2.21.0
• 2.21.1
• 2.21.2
• 2.21.3
• 2.21.4
• 2.21.5
• 2.21.6
• 2.21.7
• 2.21.8
• 2.21.9
• 2.21.10
• 2.21.11
• 2.21.12
• 2.21.13
• 2.21.14
• 2.21.15
• 2.21.16
• 2.21.17

License

• open-source

Website

• Vendor: https://www.apache.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion