On 2018-03-31, Dominik Stadler wrote:
> 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.
This is using java.util.zip.ZipFile, not Commons Compress, right? I just
want to double check.
> 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.
At least in Commons Compress, if you use ZipFile - as opposed to
ZipArchiveInputStream then the compressed and uncompressed sizes of each
ZipArchiveEntry are known before you try to read th stream. Can't you
simply reject reading entries who's uncompressed size is too big?
If you want to handle it on the stream level, there is a
BoundedInputStream class in Commons Compress that you could wrap around
the stream returned by ZipFile#getInputStream in order to enforce an
upper limit of bytes being read. This stream class expects to be used in
a certain context, though, and won't close the wrapped stream when close
is called - if you want to go down this route, you'll have to close the
underlying stream yourself.
Hope this helps
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
