CVE-2023-34455 in snappy-javainfo

Summary

by MITRE • 06/15/2023

snappy-java is a fast compressor/decompressor for Java. Due to use of an unchecked chunk length, an unrecoverable fatal error can occur in versions prior to 1.1.10.1.

The code in the function hasNextChunk in the fileSnappyInputStream.java checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk.

In the case that the `compressed` variable is null, a byte array is allocated with the size given by the input data. Since the code doesn’t test the legality of the `chunkSize` variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a `java.lang.NegativeArraySizeException` exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal `java.lang.OutOfMemoryError` error.

Version 1.1.10.1 contains a patch for this issue.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 06/16/2023

The vulnerability identified as CVE-2023-34455 affects the snappy-java library, a widely used Java implementation for fast compression and decompression operations. This library serves as a critical component in numerous applications requiring efficient data processing, particularly in big data environments and distributed systems where compression performance is essential. The flaw resides in the SnappyInputStream.java file within the hasNextChunk function, which handles the parsing of compressed data chunks during decompression operations. The vulnerability represents a classic case of insufficient input validation that can lead to severe runtime consequences affecting system stability and availability.

The technical implementation flaw occurs in the chunk processing logic where the code attempts to read a 4-byte chunk length value from the input stream without proper validation of the resulting value. When the compressed data stream contains malformed chunk size information, the system fails to validate whether the chunk size represents a legitimate positive integer value. Specifically, the code treats the raw 4-byte input directly as an unsigned integer representing chunk size, without checking for negative values or excessively large values that could cause system resources to be exhausted. This unchecked assumption creates a direct pathway for exploitation through crafted malicious input data that can manipulate the chunk size parameter to either negative values or extremely large positive values.

The operational impact of this vulnerability manifests through two distinct but equally dangerous failure modes that can compromise system stability and availability. The first scenario occurs when a negative chunk size value is processed, typically when the input contains values like 0xFFFFFFFF which represents -1 in signed integer arithmetic. This causes a java.lang.NegativeArraySizeException to be thrown, which terminates the decompression process and can lead to application crashes or service interruptions. The more severe consequence arises when extremely large positive values are passed, such as 0x7FFFFFFF, which can trigger a java.lang.OutOfMemoryError. This type of error consumes excessive heap memory resources and can cause the entire Java Virtual Machine to crash or become unresponsive, effectively creating a denial of service condition that impacts the availability of applications relying on the snappy-java library.

This vulnerability maps directly to CWE-129, Insufficient Input Validation, and CWE-704, Incorrect Type Conversion, as the code fails to validate input parameters and properly handle type conversions between different integer representations. The attack pattern aligns with ATT&CK technique T1499.004, Network Denial of Service, and T1550.001, Application Access Token, as it can be leveraged to disrupt services through memory exhaustion or process termination. The vulnerability demonstrates a fundamental security weakness in defensive programming practices where input validation is omitted before critical system operations. The patch implemented in version 1.1.10.1 addresses this by introducing proper validation checks for chunk size values, ensuring that only legitimate positive integer values are accepted and processed, thereby preventing both the negative array size exception and the out-of-memory conditions through bounds checking and appropriate error handling mechanisms.

Responsible

GitHub, Inc.

Reservation

06/06/2023

Disclosure

06/15/2023

Moderation

accepted

CPE

ready

EPSS

0.01762

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!