CryptoAPIDecryptor: don't size the descriptor array from an untrusted count - #1347

CryptoAPIDecryptor.getSummaryEntries reads the stream descriptor count as an unsigned 32-bit field and uses it directly as an array length, with no bound at all:

int encryptedStreamDescriptorCount = Math.toIntExact(leis.readUInt());
StreamDescriptorEntry[] entries = new StreamDescriptorEntry[encryptedStreamDescriptorCount];

A crafted encrypted stream can therefore ask for a billion-element StreamDescriptorEntry[] from a handful of input bytes, before any entry data is read.

What a real count looks like

The encrypted summary stream carries the property set streams (MS-OFFCRYPTO 2.3.5.4 RC4 CryptoAPI Encrypted Summary Stream), so a real file declares 2 — SummaryInformation and DocumentSummaryInformation. Instrumenting the sample in TestDocumentEncryption confirms it: 2 entries in 128 bytes.

Bound

Rather than pick a fixed cap — any number would be a guess, and a guess can reject a valid file — the bound is derived from the data. Every entry occupies at least 18 bytes (streamOffset 4 + streamSize 4 + block 2 + nameSize 1 + flags 1 + reserved2 4 + terminator 2), and the stream is already read fully into a byte[], so a declared count larger than the bytes following it is necessarily bogus:

final long encryptedStreamDescriptorCount = leis.readUInt();
final long remaining = summary.length - (streamDescriptorArrayOffset + 4L);
final long maxDescriptorCount = remaining / STREAM_DESCRIPTOR_MIN_SIZE;
if (encryptedStreamDescriptorCount > maxDescriptorCount) {
    throw new IOException("Declared stream descriptor count " + ... );
}

This cannot reject a well formed file however many streams it carries — the bytes have to be there either way.

The entries are then collected as they are parsed rather than pre-allocated, so memory stays proportional to the data actually present:

List<StreamDescriptorEntry> entries = new ArrayList<>();
for (long i = 0; i < encryptedStreamDescriptorCount; i++) { ... }

entries was only consumed by an enhanced-for loop, so a List drops in for the array.

Reading the encrypted stream moves into a small readEncryptedStream helper so the byte[] length is available for the bound. InputStream.available() is banned by forbiddenapis, and its message points at exactly this pattern — "use IOUtils.toByteArray to read the stream fully and then count the available bytes" — which is what the method already did.

Context

Found while sweeping Math.toIntExact call sites after #1345. It was the only genuinely unbounded allocation the sweep turned up; the separate HwmfBitmapDib cleanup is #1346.

Tests

:poi:test --tests 'org.apache.poi.poifs.crypt.*' and :poi-scratchpad:test --tests 'org.apache.poi.hslf.record.TestDocumentEncryption' pass (32 tests), and forbiddenApisMain / forbiddenApisTest are clean across poi, poi-scratchpad and poi-examples.

🤖 Generated with Claude Code