Conversation
SnappyFramedInputStream.ensureBuffer() trusted the attacker-controlled Snappy length-prefix when sizing decompression buffers: a ~23-byte frame could declare a multi-GB uncompressed length and force direct-ByteBuffer and byte[] allocations of that size before the frame CRC32C is checked (CWE-770, issue xerial#730). The compressed chunk length is bounded (~16 MiB) but the declared uncompressed length had no ceiling at all. Reject declared lengths above SnappyInputStream.MAX_CHUNK_SIZE (512 MiB), the ceiling already used for the sibling block-format class since the CVE-2023-43642 fix. Frames declaring more than that can only be hostile: conforming writers emit at most 64 KiB per chunk, and larger non-conforming producers stay within the bound.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
Fixes #730 — unbounded allocation from an attacker-declared uncompressed length in
SnappyFramedInputStream.ensureBuffer()(CWE-770, CVSS 5.3), reported by August829.Root cause
ensureBuffer()reads the declared uncompressed length from the fully attacker-controlled Snappy length-prefix inside a compressed-data frame and sizes the directByteBuffer+byte[]decompression buffers with it — before the frame's CRC32C is verified.getFrameMetaData()bounds only the compressed chunk length (~16 MiB via the 3-byte chunk header); the declared uncompressed length had no ceiling at all, so a ~23-byte frame could drive a multi-GB allocation (OOM DoS of any process decompressing untrusted x-snappy-framed input).Fix
Reject a declared uncompressed length above
SnappyInputStream.MAX_CHUNK_SIZE(512 MiB) — the ceiling upstream already uses for the sibling block-format class since the CVE-2023-43642 fix. A frame declaring more than that can only be hostile: conforming x-snappy-framed writers emit at most 64 KiB uncompressed per chunk, and snappy-java's ownSnappyFramedOutputStreamhard-limitsblockSizetoMAX_BLOCK_SIZE.Choosing the 512 MiB bound rather than the 64 KiB spec limit keeps the reader tolerant of non-conforming producers, matching the existing test suite (
testLargerFrames_*writes single frames that decompress to 100–500 KiB).Tests
New regression test
testDeclaredUncompressedLengthExceedsMaxBlockSizecrafts a framed stream whose Snappy block declares 1 GiB uncompressed followed by a single literal byte; pre-fix it allocates ~1 GiB and fails on checksum, post-fix it throwsSnappyIOException(INVALID_CHUNK_SIZE)before any allocation../sbt "testOnly org.xerial.snappy.SnappyFramedStreamTest": 18/18 pass.