CVE-2021-37137: Netty Snappy Frame Decoder DoS Vulnerability

CVE-2021-37137 Overview

CVE-2021-37137 is a resource exhaustion vulnerability in Netty's Snappy frame decoder function. The decoder fails to restrict chunk length during decompression operations, which can lead to excessive memory usage. Additionally, the decoder may buffer reserved skippable chunks until the entire chunk is received, compounding the memory exhaustion issue. Attackers can exploit this vulnerability by supplying malicious input that decompresses to an extremely large size via a network stream or file, or by sending oversized skippable chunks.

Critical Impact

Remote attackers can trigger denial of service conditions by causing excessive memory consumption in applications using Netty's Snappy compression functionality, potentially crashing services or making them unresponsive.

Affected Products

• Netty (versions prior to fix)
• Oracle Banking APIs (versions 19.1, 19.2, 20.1, 21.1)
• Oracle Banking Digital Experience (versions 18.1, 18.2, 18.3, 19.1, 19.2, 20.1, 21.1)
• Oracle Commerce Guided Search (version 11.3.2)
• Oracle Communications BRM - Elastic Charging Engine (version 12.0.0.5.0)
• Oracle Communications Cloud Native Core Binding Support Function (version 1.10.0)
• Oracle Communications Diameter Signaling Router
• Oracle PeopleSoft Enterprise PeopleTools (versions 8.57, 8.58, 8.59)
• Oracle WebCenter Portal (versions 12.2.1.3.0, 12.2.1.4.0)
• Quarkus
• NetApp OnCommand Insight
• Debian Linux (versions 10.0, 11.0)

Discovery Timeline

• October 19, 2021 - CVE-2021-37137 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2021-37137

Vulnerability Analysis

This vulnerability falls under CWE-400 (Uncontrolled Resource Consumption), a class of weaknesses where an application fails to properly limit resource allocation in response to user input. In Netty's Snappy frame decoder implementation, the absence of chunk length restrictions creates an avenue for resource exhaustion attacks.

The vulnerability affects the Snappy compression codec within Netty, a widely-used asynchronous event-driven network application framework. Snappy is a fast compression algorithm developed by Google, and Netty implements frame-based decompression to handle streaming data. The decoder's failure to validate or limit incoming chunk sizes before buffering allows malicious actors to craft payloads that consume disproportionate amounts of memory during decompression.

Root Cause

The root cause lies in the Snappy frame decoder's lack of input validation for chunk lengths. When processing compressed Snappy frames, the decoder accepts chunks of arbitrary size without enforcing upper bounds. This design flaw manifests in two ways:

1. Unrestricted decompression expansion: The decoder does not limit how large decompressed data can grow, allowing small compressed payloads to expand into massive memory allocations.

2. Unbounded skippable chunk buffering: Reserved skippable chunks in the Snappy format are buffered entirely in memory before processing. Without size limits, attackers can send enormous skippable chunks that exhaust available heap space.

Attack Vector

The attack can be executed remotely over the network without authentication. An attacker can exploit this vulnerability through several methods:

1. Malicious compressed payloads: Crafting Snappy-compressed data with high compression ratios that expand to consume gigabytes of memory when decompressed.

2. Oversized skippable chunks: Sending specially crafted Snappy frames containing reserved skippable chunks with maximum length values, forcing the decoder to allocate large memory buffers.

3. Streaming attacks: Continuously sending malicious compressed data through network streams to gradually exhaust server memory resources.

The attack requires no user interaction and can be triggered by any network-accessible service using Netty's Snappy codec for data compression.

Detection Methods for CVE-2021-37137

Indicators of Compromise

• Abnormal memory consumption spikes in Java applications using Netty
• Heap memory exhaustion errors or OutOfMemoryError exceptions in application logs
• Unusual network traffic patterns involving compressed data streams
• Service unresponsiveness or crashes following receipt of compressed payloads

Detection Strategies

• Monitor JVM heap usage for sudden, unexplained increases during compressed data processing
• Implement application performance monitoring (APM) to detect memory allocation anomalies
• Review application dependencies to identify vulnerable Netty versions in your software stack
• Configure alerting for OutOfMemoryError exceptions in production environments

Monitoring Recommendations

• Set up memory threshold alerts for applications using Netty's Snappy codec
• Enable garbage collection logging to identify memory pressure patterns
• Monitor network traffic for unusually large or malformed Snappy-compressed payloads
• Implement rate limiting on endpoints that accept compressed data

How to Mitigate CVE-2021-37137

Immediate Actions Required

• Upgrade Netty to a patched version that includes chunk length validation
• Review and update all applications and frameworks that bundle Netty as a dependency
• Implement input size validation at the application layer as a defense-in-depth measure
• Configure JVM memory limits to prevent complete system exhaustion during attacks

Patch Information

Multiple vendors have released patches addressing this vulnerability. Oracle has included fixes in their Critical Patch Updates, documented in the Oracle Security Alert January 2022, Oracle Security Alert April 2022, and Oracle Security Alert July 2022. Debian has released security updates documented in Debian Security Announcement DSA-5316. NetApp has issued guidance in NetApp Security Advisory NTAP-20220210-0012. For complete details on the vulnerability, refer to the GitHub Security Advisory GHSA-9vjp-v76f-g363.

Workarounds

• Disable Snappy compression if not required for application functionality
• Implement proxy-level inspection to reject oversized compressed payloads before they reach the application
• Configure network-level rate limiting to reduce the impact of sustained attacks
• Deploy applications in containerized environments with strict memory limits to contain resource exhaustion

# Example: JVM memory configuration to limit heap exhaustion impact
java -Xmx2g -Xms1g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/heapdumps -jar application.jar