|Summary:||'zip' bomb prevention|
|Product:||POI||Reporter:||Martijn Brinkers <martijn>|
|Component:||POI Overall||Assignee:||POI Developers List <dev>|
|Bug Depends on:|
|Attachments:||[Patch] Zip bomb patch|
Description Martijn Brinkers 2010-10-13 15:24:37 UTC
POI uses InflaterInputStream in multiple places for decompression of images etc. The InflaterInputStream is used without any limit on the number of bytes written after deflating. This makes POI vulnerable to a 'zip' bomb which is a very large file (possible multiple GBs) with only zero bytes. Because the file only contains zero's the compressed file is very small. To protect against a 'zip' bomb, the output from the InflaterInputStream should be wrapped in a stream that only accepts a certain amount of bytes. My suggestion would be to allow POI users to register a global output buffer factory (or something like that) that allows the POI user to modify how a buffer is used globally. A POI user can then decide whether the buffer should stream to disk and or set a limit on the number of bytes accepted.
Comment 1 David Fisher 2010-10-13 16:53:11 UTC
Another idea would be to implement a system parameter that limits the expansion. The default would set rather large. Say if the compressed size is 100 bytes and the "maxinflatorfactor" is set to 2000 then the maximum size of the expanded item is limited to 200,000 bytes. I'll leave it to others to estimate the number of places this should be done. There really are more than a few.
Comment 2 Martijn Brinkers 2010-10-13 16:57:03 UTC
Yes using an expansion limit is another solution. However personally I prefer that you can specify an upper limit. A solution which allows the POI user from implementing his/her own method of checking whether the output reaches some limit is therefore the most flexible I think.
Comment 3 Andreas Beeker 2015-06-20 15:39:26 UTC
Created attachment 32839 [details] [Patch] Zip bomb patch Here is my zip bomb patch. I had to reflect into the ZipFile class to get to the raw bits, which might be a problem with Java 9. Furthermore there might be a slight decrease in OOXML processing performance, which I haven't profiled. Should there be an option to bypass the new handling? If nobody complaints, I'll apply the patch on 24.06.2015 and check the jenkins results for other runtimes.