Overview

Apache has released a security update to address an important Apache Tomcat vulnerability (CVE-2024-56337) that could result in remote code execution (RCE) under certain conditions. This new CVE is closely tied to the earlier Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability during JSP compilation (CVE-2024-50379), for which an incomplete mitigation was issued on December 17, 2024. Both flaws hinge on the same underlying mechanism—a Time-of-check Time-of-use (TOCTOU) race condition in Apache Tomcat—meaning that the checks and the actual operations on files can get out of sync, allowing attackers to slip malicious code into the system.

A Quick Recap

  • CVE-2024-50379 is the original vulnerability with a CVSS score of 9.8, which allowed remote attackers to bypass Tomcat’s case sensitivity checks and treat an uploaded file as a JSP file (meaning it can be executed by the server), leading to RCE.
  • CVE-2024-56337 was subsequently assigned to highlight that the initial fix for CVE-2024-50379 was incomplete. Certain manual steps are required, depending on your Java version, to fully close the gap.

Products and Versions Affected

  • Apache Tomcat 11.0.0-M1 through 11.0.1
  • Apache Tomcat 10.1.0-M1 through 10.1.33
  • Apache Tomcat 9.0.0.M1 through 9.0.97

The issue is fixed in Apache Tomcat 11.0.2, 10.1.34, and 9.0.98, but users should read the additional mitigation steps below, as some Java configurations still require manual intervention.


Why It’s a TOCTOU Race Condition

TOCTOU in a Nutshell

A Time-of-check Time-of-use (TOCTOU) vulnerability happens when a program checks something (time of check) but doesn’t immediately act on that information (time of use). If an attacker changes the resource in the narrow window between these two steps, they can bypass security checks.

Why Tomcat Is at Risk

On case-insensitive file systems (e.g., Windows) with default servlet write enabled, Tomcat checks if a file is safe, but an attacker can rename or tweak that file just before Tomcat actually uses it. Under high concurrency, this trick can let malicious JSP files slip through and be executed.

Specifics of CVE-2024-56337

Apache Tomcat’s maintainers discovered that the fix for CVE-2024-50379 did not adequately handle all configurations, especially on systems with:

  • Case-insensitive file systems (e.g., Windows, macOS with APFS set to be case-insensitive, certain network file systems).
  • Default servlet write enabled (readonly initialization parameter set to false).

Java Version Dependencies

An additional twist is that different Java versions manage internal file path caches differently. Specifically:

  1. Java 8 or Java 11:
    • sun.io.useCanonCaches must be explicitly set to false (the default is true), or you remain exposed.
  2. Java 17:
    • If sun.io.useCanonCaches is set, it must be false (the default is already false).
    • Double-check for any environment where it might have been overridden to true.
  3. Java 21 and later:
    • No additional configuration is required. The property and the problematic cache mechanism have been removed from these newer Java releases.

Upcoming Enhancements

  • Tomcat 11.0.3, 10.1.35, and 9.0.99 and onwards will introduce extra checks to ensure sun.io.useCanonCaches is set appropriately before allowing the default servlet to be write-enabled on case-insensitive file systems.
  • Tomcat will also set sun.io.useCanonCaches to false by default where feasible, further reducing the risk of a race condition.

How TOCTOU Leads to Remote Code Execution

  1. File Upload: The attacker uploads a file that looks harmless.
  2. Rename on Case-Insensitive File System: Right after Tomcat’s “safe file?” check, the attacker changes .txt to something like .jsp.
  3. Execution: Tomcat sees the file as JSP code and runs it, giving the attacker control.

This exploit hinges on the tiny delay between Tomcat’s “check” and its “use.” By staying up to date, setting the right Java property, and disabling servlet write access unless you need it, you can dodge this TOCTOU bullet.

Additional Mitigation and Recommendations

  1. Set sun.io.useCanonCaches Appropriately:
    • Java 8 / Java 11: -Dsun.io.useCanonCaches=false
    • Java 17: Confirm it remains false (or unset), as the default is already false.
    • Java 21+: No action required.
  2. Disable Default Servlet Write Unless You Need It: By default, Tomcat’s default servlet is read-only. If your environment does not need runtime file uploads, keep this parameter set to true so that the default servlet cannot be used to write new files.

How Upwind Helps Protect You From Uprising Zero-Days

Upwind’s Cloud Security Platform provides powerful tools to address and mitigate the risks associated with:

1. Inventory Visibility: Identify which compute assets with Apache Tomcat.

2. Vulnerability Management and Feed: Utilize Upwind’s SBOM Explorer to identify and monitor the use of Apache Tomcat throughout your environment, while receiving push notifications about any risks detected.

Screenshot of the Upwind SBOM Explorer showing a list of software components. It includes columns for name, version, CVEs, framework, license, package manager, affected images, and resources. Blue arrows point to the dashboard navigation.

3. Risk Prioritization: Understand the impact of this vulnerability in high-risk environments and prioritize upgrades or mitigations.

Screenshot of an SBOM explorer interface displaying package details for tomcat-embed-core. The right panel shows Package usage with tabs for image name, version, and resource name. Various package versions and related icons are visible.

4. Continuous Monitoring: Upwind provides real-time detection of configuration issues and alerts for potential exploits.

    To learn more about how Upwind protects against emerging critical vulnerabilities, schedule a demo.