sorry it's a litte bit late, but have you tried to open an bug-report for
the hard cast on https://bugreport.java.com/ ?


Robert Paasche
Senior Developer

pripares GmbH
Altheimer Eck 2
80331 München

Tel  +49 (0)89 45 22 808 - 30
Fax  +49 (0)89 45 22 808 - 58
Mail r.paas...@pripares.com
Web  www.pripares.com

Handelsregister: Registergericht München HRB 138701
Sitz der Gesellschaft: München
Geschäftsführer: Aßmann Christoph, Ertl Andreas

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
löschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail und der darin enthaltenen Informationen sind nicht

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

2018-03-31 10:26 GMT+02:00 Dominik Stadler <cen...@apache.org>:

> Hi,
> Apache POI is opening zip-files on a regular basis because Microsoft
> Excel/Word/... files are zip-files in their newer format. In order to
> prevent some types of denial-of-service-attacks, we have added
> functionality when opening Zip-files to not read files which expand a lot
> and thus could be used to overwhelm the main memory by providing small
> malicious file which explodes when uncompressed into memory. We call this
> zip-bomb protection.
> Up to Java 9 we could use some workaround via reflection to inject a
> counting-InputStream into ZipFile/ZipEntry to detect an explosion in
> expanded data and this way prevent zip-bombs.
> However in Java 10 this is not possible any more because the
> implementation of ZipFile was changed in a way that prevents this (hard
> cast to ZipFile$ZipFileInputStream in ZipFile).
> So we are looking for a different way to count the number of extracted
> bytes while extracting to be able to stop as soon as the compression ratio
> reaches a certain limit.
> Could we do this with Commons Compress? I.e. wrap the InputStreams with
> some counting so that we can stop during extracting.
> Or does anybody know of a way to do zip-bomb-detection differently without
> resorting to reflection?
> Thanks... Dominik.
> Apache POI PMC/Comitter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to