Published: June 2024

Overview

A serious vulnerability, tracked as CVE-2024-56337 [NVD link], has been discovered in Apache Tomcat, one of the most widely used Java web servers. This post explains the vulnerability in simple terms, shares code snippets to illustrate the problem, and gives practical mitigation steps. If you’re running Tomcat on a case-insensitive file system (Windows, macOS, or some mounted volumes) with the default servlet write feature enabled (readonly=false), you may be exposed to this risk.

What is the Problem: A Time-of-check Time-of-use (TOCTOU) Vulnerability

A TOCTOU (time-of-check time-of-use) race condition is a classic security bug where the code checks for a condition and then acts on it — but the state changes between check and use, leading to security bypasses.

In Tomcat:
This bug affects the “default” servlet, which handles static files. If write access is enabled, there is a race between checking if a file path is allowed and the real file operation. When Tomcat runs on a case-insensitive file system, attackers can manipulate the filename during the small window between check & use, bypassing security controls.

Why Did This Happen? Incomplete Fix for CVE-2024-50379

Tomcat developers previously tried to fix a related vulnerability (CVE-2024-50379), but overlooked certain Java behaviors on case-insensitive file systems. The problem mainly affects Java 8 and Java 11, where a file caching system (sun.io.useCanonCaches) can let attackers bypass new security checks.

Attack Scenario

1. Precondition: Attacker has permissions to upload or overwrite files via Tomcat’s default servlet (which should normally be readonly, but here is set to writable).
2. Step 1: Attacker requests an upload or write to a path with one case (e.g., /WEB-INF/test.TXT).
3. Step 2: Very quickly, before the underlying file operation, the attacker (via a race) swaps or renames files in the file system—changing the “real” file to (for example) a symlink, or different case (test.txt vs TEST.TXT).

Here’s a simplified pseudo-code to illustrate

public void writeFile(String path, byte[] data) {
    // (1) Check: does this path seem safe?
    if (!isPathSafe(path)) {
        throw new SecurityException("Unsafe path!");
    }

    // (2) TOCTOU bug: attacker swaps file here!
    // (3) Use: write data to file
    Files.write(Paths.get(path), data);
}

On a case-insensitive file system, under certain Java versions, Files.write() and isPathSafe() can disagree about what file is being accessed, especially if the file was swapped or renamed just after the check.

Here is a simplified local attack scenario (for educational/research purposes only)

# Assume attacker has upload/write access via vulnerable Tomcat server

# Step 1: Upload to /data/test.txt (safe per Tomcat's check)

# Step 2: While upload is being processed, attacker quickly renames or symlinks test.txt to sensitive_file.txt

# Step 3: The race winner: Tomcat writes attacker’s data into sensitive_file.txt

A Python script can be used to swap files in a tight loop during an upload, racing against Tomcat.

Why Does sun.io.useCanonCaches Matter?

This property controls Java’s internal caching of file canonical paths. If enabled (default on Java 8/11), an attacker might exploit this cache for easier timing and confusion of file identities, especially on case-insensitive file systems.

On Java 8/11:
You *must* explicitly set this to false to block this caching behavior.

Use 9..99, 10.1.35, or 11..3 (or later)

- Apache Tomcat downloads

If you can’t upgrade:

- *Java 8 or 11*: Set system property -Dsun.io.useCanonCaches=false in your Tomcat JAVA_OPTS or catalina.sh/catalina.bat

`

3. Best practice: Unless absolutely needed, leave the readonly parameter for the default servlet to true. Never allow write from the web unless you fully trust your users and your filesystem setup.

References and More Reading

- CVE-2024-56337 official advisory (NVD)
- Apache Tomcat Security page
- Previous fix: CVE-2024-50379
- Tomcat 9..99 release notes

Conclusion

CVE-2024-56337 is a textbook example of a TOCTOU bug, with real-world impact for those running Tomcat in less-secure configurations.

Upgrade now if you use a default servlet in writable mode.

- Set the system property for Java 8/11 for extra safety.

Never enable writable default servlet unless you must — readonly is much safer.

Stay proactive, check your Java and Tomcat versions, and always follow security advisories for your software stack.


*This exclusive writeup aims to break down the risk, show possible exploits, and give simple advice for protection. If you think your organization might be exposed, act now!*

Timeline

Published on: 12/20/2024 16:15:24 UTC
Last modified on: 12/31/2024 19:15:47 UTC