Hi, 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/ ?
Best Rob 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 gestattet. 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 > >