https://bz.apache.org/bugzilla/show_bug.cgi?id=66840
cnj_0304 <cnj_0...@qq.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|1 |0
Status|RESOLVED |UNCONFIRMED
Resolution|INFORMATIONPROVIDED |---
--- Comment #7 from cnj_0304 <cnj_0...@qq.com> ---
(In reply to PJ Fanning from comment #1)
> We know about this and there isn't much we can do. Anyone who parses
> xlsx/docx/pptx/etc. files will need to be aware that the data is compressed
> and that the resulting decompressed data can be huge.
>
> We do check for zip bombs - ie data that has a very high ratio when
> decompressing.
>
> See the setMinInflateRatio documentation in
> https://poi.apache.org/components/configuration.html
However, I found that if the payload size is less than 100 KB, the logic of
comparing compression ratios cannot be executed. I think this code has a bug.
The interfaces you mentioned above lose the meaning of user customization.
For example：
org.apache.poi.openxml4j.util.ZipSecureFile.setMinInflateRatio(double ratio)
org.apache.poi.openxml4j.util.ZipSecureFile.setMaxEntrySize(long maxEntrySize)
Problem Code：
checkThreshold()：
// check the file size first, in case we are working on uncompressed
streams
if(payloadSize > MAX_ENTRY_SIZE) {
throw new IOException(String.format(Locale.ROOT,
MAX_ENTRY_SIZE_MSG, payloadSize, rawSize, MAX_ENTRY_SIZE, entryName));
}
// don't alert for small expanded size
if (payloadSize <= GRACE_ENTRY_SIZE) {
return; // here is return
}
double ratio = rawSize / (double)payloadSize;
if (ratio >= MIN_INFLATE_RATIO) {
return;
}
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
