You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Stefan Bodewig (JIRA)" <ji...@apache.org> on 2018/03/20 09:19:00 UTC

[jira] [Commented] (COMPRESS-445) Zip Bomb Detection

    [ https://issues.apache.org/jira/browse/COMPRESS-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405994#comment-16405994 ] 

Stefan Bodewig commented on COMPRESS-445:
-----------------------------------------

Client code could always wrap the stream returned by {{ZipFile}} into something like the POI's {{ThresholdInputStream}} - or check the entry's uncompressed size before even starting the decompression. It doesn't feel right to me to bake that into {{ZipFile}} in particular as {{ZipArchiveInputStream}} and {{SevenZFile}} would need the same treatment as well (possibly even more than those, likely most of the compressor streams as well).

To me it looks as if this would better be solved in a layer on top of our abstractions.

> Zip Bomb Detection
> ------------------
>
>                 Key: COMPRESS-445
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-445
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Archivers
>            Reporter: PJ Fanning
>            Priority: Major
>
> It would be a nice feature if ZipFile had support for detecting Zip Bombs.
> Apache Poi has an implementation based on the java util ZipFile but this relies on Reflection and changes in Java 10 mean this code will not work in that version.
> [https://github.com/apache/poi/blob/trunk/src/ooxml/java/org/apache/poi/openxml4j/util/ZipSecureFile.java]
> One option would be to add equivalent change support in commons-compress and for Poi to use the commons version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)