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

CVE-2023-34455 Overview

CVE-2023-34455 is a denial-of-service vulnerability in snappy-java, a widely used compressor/decompressor library for Java maintained by Xerial. The flaw affects versions prior to 1.1.10.1 and resides in the hasNextChunk function of SnappyInputStream.java. The function reads a 4-byte chunk length from an attacker-controlled stream without validating its value. A crafted input can trigger a java.lang.NegativeArraySizeException or, worse, an unrecoverable java.lang.OutOfMemoryError. The issue is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact

Remote attackers can crash any Java service that decompresses untrusted Snappy-framed data, producing a fatal JVM error and denial of service.

Affected Products

• xerial:snappy-java versions prior to 1.1.10.1
• Java applications and frameworks bundling vulnerable snappy-java (Kafka, Spark, Hadoop, Cassandra ecosystems)
• NetApp products incorporating snappy-java (per NetApp Security Advisory ntap-20230818-0009)

Discovery Timeline

• 2023-06-15 - CVE-2023-34455 published to the National Vulnerability Database
• 2023-06-15 - Vendor advisory GHSA-qcwq-55hx-v3vh and patch commit 3bf67857 released in version 1.1.10.1
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-34455

Vulnerability Analysis

The vulnerability resides in the hasNextChunk method of SnappyInputStream.java. The method attempts to read four bytes from the underlying stream and interprets them directly as the length of the next compressed chunk. No bounds checks are applied to this value before it is used to allocate a backing byte array. When the internal compressed buffer is null, the code allocates new byte[chunkSize] using the raw attacker-supplied length.

Two distinct failure modes result. Supplying 0xFFFFFFFF (interpreted as -1 in Java's signed integer arithmetic) raises a java.lang.NegativeArraySizeException. Supplying a large positive value such as 0x7FFFFFFF triggers a java.lang.OutOfMemoryError, which is an unrecoverable JVM Error rather than a catchable Exception. The second outcome terminates the affected process or leaves the JVM in an inconsistent state.

Root Cause

The root cause is missing input validation on a length field parsed from untrusted data. The chunk length is consumed verbatim from the network or file stream and used directly as the size argument to a Java array allocation. The library does not enforce an upper bound, reject negative values, or compare the declared length against remaining stream bytes before allocating memory.

Attack Vector

The vulnerability is reachable over the network whenever a Java service decompresses Snappy-framed data from an untrusted source. No authentication or user interaction is required. Common exposure points include message brokers, RPC layers, data pipelines, and file-import functions that accept Snappy-compressed payloads. An attacker crafts a four-byte chunk-length header indicating a huge or negative size and submits it to the target. See the patched source in SnappyInputStream.java for the corrected length-validation logic.

// No verified exploit code is published for this CVE.
// The vulnerability is triggered by sending a Snappy-framed stream
// whose 4-byte chunk-length field decodes to 0xFFFFFFFF (-1) or a
// very large positive value such as 0x7FFFFFFF, causing the
// vulnerable allocation in SnappyInputStream.hasNextChunk().

Detection Methods for CVE-2023-34455

Indicators of Compromise

• Java application logs containing java.lang.OutOfMemoryError or java.lang.NegativeArraySizeException originating from org.xerial.snappy.SnappyInputStream.hasNextChunk
• Unexpected JVM termination or container restarts on services that ingest Snappy-compressed payloads
• Repeated malformed Snappy frames originating from the same remote source

Detection Strategies

• Inventory Java applications and dependencies for snappy-java versions below 1.1.10.1 using software composition analysis (SCA) tools or mvn dependency:tree and gradle dependencies
• Hunt for vulnerable JARs on disk by hashing or by scanning manifests for Bundle-Version entries under the xerial:snappy-java coordinate
• Correlate application crash events with inbound network flows carrying Snappy-framed data (Kafka, Hadoop RPC, Spark shuffle)

Monitoring Recommendations

• Forward JVM error logs and crash dumps to a centralized logging or SIEM platform and alert on OutOfMemoryError patterns from snappy stack frames
• Monitor service-restart counts and broker partition under-replication metrics that may indicate repeated DoS attempts
• Track upstream advisories from GHSA-qcwq-55hx-v3vh and NetApp ntap-20230818-0009 for downstream product fixes

How to Mitigate CVE-2023-34455

Immediate Actions Required

• Upgrade snappy-java to version 1.1.10.1 or later across all Java applications, services, and container images
• Identify transitive dependencies pulling in vulnerable versions and override them in pom.xml or build.gradle
• Restrict network exposure of services that decompress Snappy data from untrusted peers until patches are deployed
• Apply vendor-supplied updates for downstream products such as those listed in NetApp ntap-20230818-0009

Patch Information

The fix is delivered in snappy-java1.1.10.1 via commit 3bf67857. The patch validates the parsed chunkSize before allocating the backing array, rejecting negative and unreasonably large values. Refer to GHSA-qcwq-55hx-v3vh for the authoritative vendor advisory.

Workarounds

• Where immediate upgrade is impossible, place a size-limited reverse proxy or message-broker quota in front of services that accept Snappy-compressed input
• Validate or strip Snappy frames at an application gateway before they reach the vulnerable decompressor
• Configure JVM resource limits and container memory ceilings so a triggered OutOfMemoryError is contained and the workload is automatically restarted by the orchestrator

# Maven: force the patched snappy-java version in dependencyManagement
# <dependencyManagement>
#   <dependencies>
#     <dependency>
#       <groupId>org.xerial.snappy</groupId>
#       <artifactId>snappy-java</artifactId>
#       <version>1.1.10.1</version>
#     </dependency>
#   </dependencies>
# </dependencyManagement>

# Gradle: pin the resolved version
# configurations.all {
#   resolutionStrategy.force 'org.xerial.snappy:snappy-java:1.1.10.1'
# }

# Verify the version actually loaded at runtime
mvn dependency:tree -Dincludes=org.xerial.snappy:snappy-java