CVE-2024-47535

What it actually does

A vulnerability in the Netty framework on Windows systems allows for a denial of service. The framework attempts to read a specific file, and if a local attacker creates an extremely large file at that location, the application will try to load it, leading to excessive memory consumption and a subsequent crash of the application process.

Why it matters to the business

Applications relying on the vulnerable Netty library can be rendered unavailable by a local, low-privileged attacker. This can lead to service outages for critical business functions, impacting customers, operations, and revenue. The requirement for local access lowers the immediate threat compared to a remote vulnerability, but it poses a significant risk on multi-user systems or as part of a post-compromise attack chain.

How an attack unfolds

An attacker with low-privileged local access to a Windows system first identifies an application using a vulnerable version of Netty. The attacker then determines the specific, predictable file path that Netty attempts to access. By creating a file of an exceptionally large size at this location, the attacker sets a trap. When the Netty-based application is next launched or performs an action that triggers the file read, it will attempt to load the entire large file into memory. This exhausts available system resources, causing the application to crash and resulting in a denial of service.

How to fix it

To remediate this vulnerability, developers must upgrade the Netty library to version 4.1.115 or later. This involves updating the dependency in the project's build configuration (e.g., pom.xml, build.gradle), rebuilding the application, and deploying the updated version. The fix is contained in commit 04f9b4a827d992ad439823eeba85d65d3a89c265 and later.

How to confirm the fix worked

To validate exposure, use a software composition analysis (SCA) tool or manually inspect application dependencies to find instances of Netty versions prior to 4.1.115 on Windows systems. To confirm the fix, verify that deployed applications are running with Netty 4.1.115 or a newer version. On a non-production system, you can attempt to reproduce the vulnerability by creating a large file in the expected path and observing if the application crashes; a patched system should not crash.

Typical attack path

1. An attacker gains local, low-privileged user access to a target Windows host.
2. The attacker identifies an application using a vulnerable version of the Netty library.
3. The attacker creates a very large file in the specific path that the Netty library attempts to read from.
4. The Netty-based application is started or performs an operation that triggers the vulnerable file read.
5. The application attempts to load the large file, exhausts memory, and crashes.

How to detect it

To detect potential exploitation, monitor for unexpected application crashes on Windows systems, particularly those related to memory exhaustion or file I/O errors. Correlate these events with file system audit logs, looking for the creation of unusually large files by low-privileged users in application directories or other predictable paths. Review application logs for errors indicating a failure to read or process a file right before a crash.

What your security team should do

• Identify all applications using the Netty library on Windows systems and prioritize patching for critical services and multi-user systems.
• Direct development teams to upgrade their projects to use Netty version 4.1.115 or newer and redeploy the applications.
• As a temporary mitigation where patching is not immediately possible, investigate tightening file system permissions to prevent low-privileged users from creating files in the path Netty attempts to read.