CVE-2023-34455: Xerial Snappy-java DOS Vulnerability

CVE-2023-34455 Overview

CVE-2023-34455 is a Denial of Service vulnerability affecting snappy-java, a fast compressor/decompressor library for Java developed by Xerial. The vulnerability exists in versions prior to 1.1.10.1 due to improper validation of chunk length values during decompression operations.

The flaw resides in the hasNextChunk function within SnappyInputStream.java, where the code reads 4 bytes from a stream and interprets them as the length of the next chunk without proper validation. This unchecked chunk length can be exploited by providing maliciously crafted input data that triggers either a java.lang.NegativeArraySizeException (when a negative value like 0xFFFFFFFF is passed) or a fatal java.lang.OutOfMemoryError (when an extremely large positive value like 0x7FFFFFFF is supplied).

Critical Impact

Attackers can cause unrecoverable application crashes and denial of service by providing specially crafted compressed data that triggers fatal memory allocation errors in Java applications using vulnerable snappy-java versions.

Affected Products

• Xerial snappy-java versions prior to 1.1.10.1

Discovery Timeline

• 2023-06-15 - CVE CVE-2023-34455 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-34455

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The issue stems from the hasNextChunk function in SnappyInputStream.java which processes compressed data streams. When the function reads chunk metadata from an input stream, it extracts a 4-byte value representing the chunk size without validating whether this value is within acceptable bounds.

When the compressed buffer variable is null, the code attempts to allocate a new byte array using the untrusted chunkSize value directly. Since Java's int type is signed, an attacker can supply a value that appears as a large positive number in the data stream but is interpreted as negative in Java (such as 0xFFFFFFFF = -1), causing a NegativeArraySizeException. Alternatively, supplying the maximum positive integer value (0x7FFFFFFF = 2,147,483,647) causes the JVM to attempt allocating approximately 2GB of memory, resulting in an unrecoverable OutOfMemoryError.

The impact is significant because OutOfMemoryError is not a standard exception but an Error in Java's hierarchy, meaning it cannot be caught and handled gracefully by most applications, leading to immediate process termination.

Root Cause

The root cause is the absence of input validation on the chunkSize variable before it is used to allocate memory. The vulnerable code path directly uses attacker-controlled data to determine memory allocation size without checking for negative values or imposing reasonable upper bounds on chunk sizes. This represents a classic resource allocation vulnerability where untrusted input directly influences resource consumption.

Attack Vector

The attack vector is network-based, requiring an attacker to supply maliciously crafted Snappy-compressed data to an application using the vulnerable library. This could occur through:

1. File Upload Endpoints - Uploading malicious compressed files to web applications
2. Data Ingestion Pipelines - Submitting crafted payloads to data processing systems
3. Message Queues - Injecting malicious compressed messages into messaging systems that use Snappy for compression

The attack requires no authentication or user interaction, making it particularly dangerous for internet-facing services.

// Security patch from SnappyInputStream.java
// Source: https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea

             }
         }
 
+        // chunkSize is negative
+        if (chunkSize < 0) {
+            throw new SnappyError(SnappyErrorCode.INVALID_CHUNK_SIZE, "chunkSize is too big or negative : " + chunkSize);
+        }
+
         // extend the compressed data buffer size
         if (compressed == null || chunkSize > compressed.length) {
-            compressed = new byte[chunkSize];
+            // chunkSize exceeds limit
+            try {
+                compressed = new byte[chunkSize];
+            }
+            catch (java.lang.OutOfMemoryError e) {
+                throw new SnappyError(SnappyErrorCode.INVALID_CHUNK_SIZE, e.getMessage());
+            }
         }
         readBytes = 0;
         while (readBytes < chunkSize) {

The patch adds explicit validation for negative chunk sizes and wraps the memory allocation in a try-catch block to convert unrecoverable OutOfMemoryError into a catchable SnappyError exception.

Detection Methods for CVE-2023-34455

Indicators of Compromise

• Unexpected java.lang.OutOfMemoryError crashes in applications processing compressed data
• java.lang.NegativeArraySizeException exceptions in application logs related to Snappy decompression
• Sudden memory spikes followed by JVM termination without graceful shutdown
• Compressed data inputs containing abnormally large or negative chunk size headers (values exceeding reasonable thresholds or 0x7FFFFFFF/0xFFFFFFFF)

Detection Strategies

• Implement software composition analysis (SCA) to identify applications using snappy-java versions prior to 1.1.10.1
• Monitor JVM crash logs and heap dumps for patterns indicating memory exhaustion during decompression operations
• Deploy application performance monitoring (APM) to detect abnormal memory allocation patterns in services handling compressed data
• Use SentinelOne's vulnerability detection capabilities to identify affected library versions across your environment

Monitoring Recommendations

• Configure alerting for OutOfMemoryError and NegativeArraySizeException events in centralized logging systems
• Monitor memory utilization trends in applications that process Snappy-compressed data streams
• Implement input size validation at application boundaries before data reaches the Snappy decompression layer
• Establish baseline memory profiles for services using snappy-java to detect anomalous allocation patterns

How to Mitigate CVE-2023-34455

Immediate Actions Required

• Upgrade snappy-java to version 1.1.10.1 or later immediately across all affected applications
• Audit your software inventory to identify all applications and services using snappy-java as a dependency
• Review transitive dependencies in your build systems (Maven, Gradle) as snappy-java may be included indirectly through other libraries
• Prioritize patching internet-facing services and data processing pipelines that accept external input

Patch Information

The vulnerability has been addressed in snappy-java version 1.1.10.1. The fix implements proper validation of chunk size values, rejecting negative values and gracefully handling memory allocation failures. The security patch is available through the official GitHub commit. Additional details are available in the GitHub Security Advisory GHSA-qcwq-55hx-v3vh. Organizations using NetApp products should also review the NetApp Security Advisory NTAP-20230818-0009.

Workarounds

• Implement input validation at application boundaries to reject suspiciously large compressed payloads before they reach the snappy-java library
• Configure JVM heap limits appropriately to minimize the impact of memory exhaustion attacks on other system components
• Deploy network-level controls to limit the size of incoming compressed data streams
• Consider implementing rate limiting on endpoints that process compressed data to reduce exposure to repeated exploitation attempts

# Maven dependency update example
# Update pom.xml to use patched version:
# <dependency>
#     <groupId>org.xerial.snappy</groupId>
#     <artifactId>snappy-java</artifactId>
#     <version>1.1.10.1</version>
# </dependency>

# Gradle dependency update:
# implementation 'org.xerial.snappy:snappy-java:1.1.10.1'

# Verify current snappy-java version in Maven project:
mvn dependency:tree | grep snappy-java

# Verify current snappy-java version in Gradle project:
gradle dependencies | grep snappy-java