Apache Tomcat vulnerability CVE-2024-50379

[JohnLivengood]

We're already getting pinged by our IT for a security vulnerability with Apache Tomcat released 12/17/24 - CVE-2024-50379.  I am operating on 11.3.  Assume I just need to wait for a patch to be released? 

The Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat allows for Remote Code Execution (RCE) on case insensitive file systems when the default servlet is enabled for write. This vulnerability affects Apache Tomcat versions 11.0.0-M1 through 11.0.1, 10.1.0-M1 through 10.1.33, and 9.0.0.M1 through 9.0.97. An attacker can exploit this vulnerability to execute arbitrary code. It is recommended to upgrade to version 11.0.2, 10.1.34, or 9.0.08 to fix this issue.

Impact: If this vulnerability is exploited, an attacker can execute arbitrary code on the affected system, potentially leading to a complete compromise of the system.

Remediation: Apply the latest patches and updates provided by the respective vendors.

[TimWestern]

This is actually an interesting question, because, They announced deprecation of ArcGIS Maps SDK for Java in march of 2024.  https://support.esri.com/en-us/knowledge-base/arcgis-maps-sdk-for-java-deprecation-000032164 
also noted with the notice at the top of this page: https://developers.arcgis.com/java/

So if Java is not being used as an integration point, what other parts of ArcGIS that we may be deploying actually rely on Java and or Tomcat? 

[JohnLivengood]

Apache tomcat has released an update to CVE-2024-50379.  Follow at your own peril but I downloaded the latest 9.0.98 jar file and renamed to tomcat-juli.jar.  On each server I replaced the vulnerable jar file with the latest version.  After restarting the 3 enterprise services, everything is working normally and scans are clear.  

Details on the vulnerability Apache Tomcat® - Apache Tomcat 9 vulnerabilities

Downloadable repository Central Repository: org/apache/tomcat/tomcat-juli/9.0.98

I would still recommend waiting for the official patch but if you're in a hurry...

[RandallWilliams]

John, this is a dangerous, untested, and unsupported path. We do not bundle the default, unmodified Tomcat binaries with ArcGIS software. It is likely that vulnerabilities that do not impact ArcGIS software due to how we build Tomcat are now introduced by this change. We strongly recommend against in-place upgrades of 3rd party components used in our software. 

[JohnLivengood]

Believe me I understand that but telling our IT security team "it's likely that the vulnerabilities do not impact us" is not a solution.  They wanted to shut down our enterprise system entirely until a patch was released.  I work for a State Gov Agency, and they don't mess around with these scans.  

Is Esri working on a patch?  The good news is I stored the old jar files on an external drive.  My plan is to place them back when a patch is released.  But for now, everything appears to be working normally.  

[RandallWilliams]

I get that. I hear it from customers frequently. However, this is an out-of-date approach and is inconsistent with CISA's guidance. 

CISA's approach has been for organizations to provide what's called an SBOM - a Software Bill of Materials. The SBOM is a machine-readable document that lists all of the "ingredients" used to build software. 

Due to the fact that the SBOM will surface issues like this that have no practical impact on a product, CISA also provides a way to justify the presence of a vulnerability that does not actually impact software - a similar limit that automated security tooling has. To account for that, CISA provides a tool to justify the presence of these vulns - that's CISA's VEX. 

Vulnerability Exploitability eXchange (VEX) – Use Cases

Vulnerability Exploitability eXchange (VEX) - Status Justifications

Additionally, we strongly encourage customers to leverage tools like CISA's KEV catalog.

KEV provides an authoritative source of vulnerabilities that are known to have been exploited "in the wild". CVE-2024-50379 is not (yet) listed in the KEV catalog.

For this case, the VEX status justification is "Vulnerable_code_cannot_be_controlled_by_adversary" because there's not a way for an attacker to exploit this CVE in our software. This is the direction the industry is moving - away from patching due to CVSS (which is not an indicator of risk) and toward using limited resources to address issues that introduce risk - eg: demonstrably exploitable issues. 

While we update Tomcat for each release and our 11.5 release will include an updated internal application server, we have no plans to offer an out-of-cycle patch for a CVE that does not impact ArcGIS Enterprise. 

In a case like this, when organizations threaten to take a service offline to satisfy a "compliance" requirement when a vendor - who is authoritative in this discussion - provides evidence that the issue is not exploitable, the organization in fact causes a high severity (CVSSv31 7.5) denial of service against themselves. We welcome additional conversation regarding our vulnerability handling process. Feel free to shoot me a DM and we can arrange a discussion with your CISO and other stakeholders. 

[JohnLivengood]

Welcome to State Government.  We thrive on out-of-date approaches.  

[RandallWilliams · Accepted solution]

Hi All,

While automated vulnerability scanners will complain about CVE-2024-50379, this CVE has no impact on ArcGIS software. A challenge with almost all of these tools is that they are good at comparing a given software product/version against a database of known vulnerabilities, they are typically unable to validate exploitability. 

In this case, Esri software is not impacted by CVE-2024-50379 because we do not configure the default servlet to enable write (readonly initialisation parameter set to the non-default value of false). We also don't enable the PUT method at the application server level. 

Note also that this CVE would typically only impact Windows - Linux based file systems are case sensitive. 

[RandallWilliams]

For completeness - ^^^ This same response also applies to CVE-2024-56337 . These are basically the same bugs, but the mitigation for CVE-2024-50379 was incomplete. We have recently updated our 3rd party CVE response app to reflect the above stance for CVE-2024-50379. That app is found in the "Customer Exclusive" document repository in the ArcGIS Trust Center. 

[Jay_Geisen]

Randall, can we assume the same holds true (no impact) for CVE-2025-24813