CVE-2023-43642: Xerial Snappy-java DoS Vulnerability

CVE-2023-43642 Overview

CVE-2023-43642 is a Denial of Service (DoS) vulnerability in snappy-java, a Java port of the snappy fast C++ compressor/decompressor developed by Google. The SnappyInputStream class was found to be vulnerable to DoS attacks when decompressing data with an excessively large chunk size. Due to a missing upper bound check on chunk length, an unrecoverable fatal error can occur, causing the application to crash.

Critical Impact

All versions of snappy-java up to and including version 1.1.10.3 are vulnerable to this Denial of Service attack, which can cause unrecoverable fatal errors in applications processing malicious compressed data.

Affected Products

• Xerial snappy-java versions prior to 1.1.10.4
• All applications using the SnappyInputStream class for decompression
• Java applications integrating snappy-java compression library

Discovery Timeline

• 2023-09-25 - CVE-2023-43642 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-43642

Vulnerability Analysis

This vulnerability falls under CWE-770 (Allocation of Resources Without Limits or Throttling). The SnappyInputStream class fails to validate the chunk size specified in compressed data streams before attempting to allocate memory for decompression operations. When processing maliciously crafted compressed data containing an extremely large chunk size value, the application attempts to allocate excessive memory resources, leading to an unrecoverable fatal error.

The vulnerability is exploitable over the network without requiring authentication or user interaction. An attacker can craft a malicious compressed data payload with an oversized chunk length value and send it to any application using snappy-java for decompression, resulting in a complete denial of service.

Root Cause

The root cause is a missing upper bound validation check on the chunk length parameter in the SnappyInputStream class. Without this boundary check, the decompression routine accepts arbitrarily large chunk sizes, leading to resource exhaustion when the application attempts to allocate memory buffers proportional to the malicious chunk size value.

Attack Vector

The attack vector is network-based, requiring no privileges or user interaction. An attacker sends specially crafted compressed data to a vulnerable application endpoint that processes snappy-compressed content. The malicious payload contains an inflated chunk size value that triggers excessive memory allocation during the decompression process. This causes an unrecoverable fatal error, effectively crashing the application and denying service to legitimate users.

// Security patch introducing MAX_CHUNK_SIZE limit
// Source: https://github.com/xerial/snappy-java/commit/9f8c3cf74223ed0a8a834134be9c917b9f10ceb5

public class SnappyInputStream
        extends InputStream
{
    public static final int MAX_CHUNK_SIZE = 512 * 1024 * 1024; // 512 MiB

    private boolean finishedReading = false;
    protected final InputStream in;
    private final int maxChunkSize;

    private byte[] compressed;
    private byte[] uncompressed;

The patch introduces a MAX_CHUNK_SIZE constant of 512 MiB and adds validation to reject chunk sizes exceeding this limit, preventing resource exhaustion attacks.

Detection Methods for CVE-2023-43642

Indicators of Compromise

• Unexpected application crashes or out-of-memory errors during decompression operations
• Abnormal memory consumption spikes in Java processes handling compressed data
• Log entries indicating fatal errors in SnappyInputStream class methods
• Network traffic containing unusually large compressed data payloads

Detection Strategies

• Monitor Java application memory usage for sudden spikes during decompression activities
• Implement application-level logging to track chunk sizes in incoming compressed data streams
• Use dependency scanning tools to identify vulnerable snappy-java versions (< 1.1.10.4) in your codebase
• Deploy network intrusion detection rules to identify suspiciously large compressed payloads

Monitoring Recommendations

• Configure JVM monitoring to alert on abnormal heap allocation patterns
• Set up application performance monitoring (APM) to track decompression operation metrics
• Monitor garbage collection activity for signs of memory pressure during data processing
• Implement rate limiting on endpoints that accept compressed data

How to Mitigate CVE-2023-43642

Immediate Actions Required

• Upgrade snappy-java to version 1.1.10.4 or later immediately
• Audit all applications using snappy-java for decompression functionality
• Implement input validation on compressed data sources before processing
• Consider temporarily disabling endpoints that accept compressed data from untrusted sources

Patch Information

A fix has been introduced in commit 9f8c3cf74 which is included in the 1.1.10.4 release. Users are advised to upgrade to version 1.1.10.4 or later. The patch adds a MAX_CHUNK_SIZE constant of 512 MiB and implements validation to reject chunk sizes exceeding this limit. For more details, see the GitHub Security Advisory GHSA-55g7-9cwv-5qfv.

Workarounds

• Only accept compressed data from trusted sources until the patch can be applied
• Implement application-level validation to check compressed data chunk sizes before passing to snappy-java
• Deploy network-level filtering to block oversized compressed payloads
• Consider using alternative compression libraries temporarily if upgrade is not immediately possible

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

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