GHSA-q233-g92q-qxp6: High severity maven/org.xerial.snappy:snappy-java vulnerability
Impact Several decompression paths in snappy-java allocate an output buffer sized by the uncompressed length declared in the first bytes of the compressed data, before decompressing or validating it. A few bytes of crafted input can therefore force an allocation of up to 2 GB, causing OutOfMemoryError (denial of service), or a NegativeArraySizeException for declared lengths of 2^31 or more.
Affected entry points include Snappy.uncompress(byte[]), Snappy.uncompressString, the Snappy.uncompressArray methods, SnappyInputStream, and SnappyFramedInputStream. The maxChunkSize limit added for CVE-2023-43642 bounds only the compressed chunk length, so it does not prevent this.
Patches Fixed in 1.1.10.9 (#739). Snappy.uncompressedLength() now rejects negative declared lengths, and lengths larger than any valid Snappy stream of the given size can produce. The densest Snappy element expands 3 bytes to 64, so the limit is 64/3 of the compressed size. Allocations are therefore proportional to the input actually received.
Workarounds Before decompressing untrusted data, check that Snappy.uncompressedLength(input) is within an application-specific limit.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.xerial.snappy:snappy-javato a version that resolves this vulnerability.Fixed in 1.1.10.9 - Upgrade
Upgrade
snappy-javato a version that resolves this vulnerability.Fixed in 1.1.10.9Patch #739 - Compensating control
Before decompressing untrusted data, check that Snappy.uncompressedLength(input) is within an application-specific limit.
Event History
Frequently Asked Questions
Which applications are exposed to denial of service?
Applications using snappy-java to decompress untrusted input through Snappy.uncompress(byte[]), Snappy.uncompressString, the Snappy.uncompress*Array methods, SnappyInputStream, or SnappyFramedInputStream are exposed. A remote attacker can send crafted compressed data that declares a very large uncompressed length.
Does the maxChunkSize limit protect against this issue?
No. maxChunkSize limits the compressed chunk length, but the vulnerable allocation is based on the declared uncompressed length, so it does not prevent oversized output-buffer allocation.
What version contains the fix?
The issue is fixed in snappy-java 1.1.10.9. The fix rejects negative declared lengths and lengths that exceed what a valid Snappy stream of the received size could produce.
What can be done if upgrading is not immediately possible?
Before decompressing untrusted data, call Snappy.uncompressedLength(input) and reject values above an application-specific limit. This prevents decompression of inputs claiming an unacceptable output size.
How can a crafted input cause an exception?
A declared uncompressed length can trigger allocation of up to 2 GB and cause OutOfMemoryError. Declared lengths of 2^31 or greater can instead cause NegativeArraySizeException.