CVE-2020-9484: Apache Tomcat RCE Vulnerability

CVE-2020-9484 Overview

CVE-2020-9484 is an insecure deserialization vulnerability affecting Apache Tomcat that enables remote code execution when specific configuration conditions are met. The vulnerability exists in the session persistence mechanism when using the PersistenceManager with a FileStore configuration.

When using vulnerable Apache Tomcat versions, if an attacker can control the contents and name of a file on the server, and the server is configured to use the PersistenceManager with a FileStore, and the sessionAttributeValueClassNameFilter is set to null (the default unless a SecurityManager is used) or a sufficiently lax filter, the attacker can trigger remote code execution via deserialization of a malicious file.

Critical Impact
This deserialization vulnerability allows attackers to achieve remote code execution on vulnerable Apache Tomcat servers when specific configuration and access conditions are met, potentially leading to complete system compromise.

Affected Products

Apache Tomcat 10.0.0-M1 to 10.0.0-M4
Apache Tomcat 9.0.0.M1 to 9.0.34
Apache Tomcat 8.5.0 to 8.5.54
Apache Tomcat 7.0.0 to 7.0.103
Debian Linux 8.0, 9.0, 10.0
openSUSE Leap 15.1
Fedora 31 and 32
Canonical Ubuntu Linux 16.04 LTS and 20.04 LTS
Multiple Oracle products including Database, FMW Platform, and Communications suite
McAfee ePolicy Orchestrator 5.9.0, 5.9.1, and 5.10.0

Discovery Timeline

2020-05-20 - CVE-2020-9484 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-9484

Vulnerability Analysis

This vulnerability is classified as CWE-502 (Deserialization of Untrusted Data). The attack requires four specific conditions to be satisfied simultaneously:

The attacker must be able to control the contents and name of a file on the server
The server must be configured to use the PersistenceManager with a FileStore
The PersistenceManager must be configured with sessionAttributeValueClassNameFilter="null" or a sufficiently permissive filter
The attacker must know the relative file path from the storage location used by FileStore to the controlled file

When all conditions are met, an attacker can craft a malicious serialized Java object that, when deserialized by Tomcat during session restoration, executes arbitrary code on the server.

Root Cause

The root cause lies in Apache Tomcat's session persistence mechanism. When the PersistenceManager is configured with FileStore, Tomcat deserializes session data from files without adequate validation of the class names being deserialized. The default configuration lacks a sessionAttributeValueClassNameFilter, which would otherwise restrict which classes can be deserialized. This allows an attacker who can place a malicious serialized object file on the system to have it deserialized during session restoration.

Attack Vector

The attack leverages the local file system access combined with Tomcat's session deserialization mechanism. An attacker must first gain the ability to write a file to the server, potentially through another vulnerability such as file upload functionality, FTP access, or shared storage. The attacker then crafts a request with a session ID that, when processed by the FileStore, causes Tomcat to load and deserialize the attacker-controlled file.

The session ID can be manipulated to include path traversal sequences (e.g., ../../path/to/malicious/file) pointing to the location of the malicious serialized object. When Tomcat attempts to restore the session, it deserializes the malicious payload, resulting in code execution with the privileges of the Tomcat process.

Detection Methods for CVE-2020-9484

Indicators of Compromise

Unusual files with .session extension appearing in unexpected directories
Session IDs containing path traversal patterns (../ sequences) in HTTP requests
Unexpected process spawning from the Tomcat Java process
Serialized Java object files appearing in web-accessible or shared directories

Detection Strategies

Monitor HTTP requests for session cookies or parameters containing path traversal sequences such as ../ or ..%2F
Implement file integrity monitoring on the Tomcat session storage directory to detect unauthorized modifications
Review Tomcat configuration files (context.xml, server.xml) for PersistenceManager and FileStore configurations
Analyze network traffic for suspicious POST requests targeting session management endpoints

Monitoring Recommendations

Enable verbose logging for Tomcat session management to capture session restoration events
Configure alerts for Java process anomalies such as unexpected network connections or child process creation
Monitor system calls from the Tomcat process for file operations outside expected directories
Implement runtime application self-protection (RASP) to detect deserialization attacks

How to Mitigate CVE-2020-9484

Immediate Actions Required

Upgrade Apache Tomcat to the latest patched version: 10.0.0-M5+, 9.0.35+, 8.5.55+, or 7.0.104+
If using PersistenceManager with FileStore, configure a strict sessionAttributeValueClassNameFilter to whitelist only expected classes
Review and restrict file upload capabilities to prevent attackers from placing malicious files on the server
Enable Java SecurityManager if not already active, which provides default protection against this vulnerability

Patch Information

Apache has released patches addressing this vulnerability across all affected version branches. Organizations should upgrade to the following minimum versions:

Apache Tomcat 10.0.0-M5 or later
Apache Tomcat 9.0.35 or later
Apache Tomcat 8.5.55 or later
Apache Tomcat 7.0.104 or later

For detailed patch information, refer to the Apache Tomcat Security Announcements. Organizations using Oracle products should consult the relevant Oracle Critical Patch Update advisories.

Workarounds

Disable the PersistenceManager if session persistence to disk is not required for your application
If FileStore must be used, configure a restrictive sessionAttributeValueClassNameFilter to allow only specific trusted classes
Implement network segmentation to limit attacker access to file system locations
Use alternative session persistence mechanisms such as JDBC-based storage with proper input validation

bash

# Example Tomcat context.xml configuration to mitigate the vulnerability
# Add a restrictive sessionAttributeValueClassNameFilter

# In your context.xml, modify the Manager configuration:
# <Manager className="org.apache.catalina.session.PersistentManager">
#     <Store className="org.apache.catalina.session.FileStore"
#            directory="/var/lib/tomcat/sessions"/>
#     <!-- Add a restrictive filter - adjust regex to match your application's session attribute classes -->
#     <SessionAttributeValueClassNameFilter>
#         java\\.lang\\.(?:Boolean|Integer|Long|String)
#     </SessionAttributeValueClassNameFilter>
# </Manager>

# Alternatively, disable PersistenceManager entirely by removing or commenting out
# the Manager configuration and using the default in-memory session management