ZIP Bomb

[Redpeppersir]

A vulnerability related to ZIP file handling has been discovered in the Jodd library. It allows attackers to exploit specially crafted high-compression ZIP files to consume a large amount of system space. A large amount of repetitive data (such as all-zero files) can be significantly compressed into a very small file when using ZIP compression. The ZIP_DEFLATED compression algorithm compresses empty data very efficiently, so even if the original file is large, the resulting ZIP file can remain very small.

[neroux]

What approach would you recommend?

[igr]

I guess we can provide "streaming" unzip, so we dont unzip to memory, but rather to stream directly to target.

Moreover, we can add a hard threshold for number of unzipped bytes (during unzipping) so we can prevent bombs

[neroux]

From what I understand, ZipUtil already does some streaming by using a 16 kilobyte buffer. I guess the OP was primarily concerned about the eventual disk space allocation.

The threshold you mentioned could address this. Could be either hardcoded or an additional parameter to unzip(). Maybe also some ratio between ZipEntry.getSize() and ZipEntry.getCompressedSize().

Apache seems to apply some similar threshold management here at https://github.com/apache/poi/blob/trunk/poi-ooxml/src/main/java/org/apache/poi/openxml4j/util/ZipArchiveThresholdInputStream.java