Streaming filter decompression

[jakiki6]

Explanation

I've recently played around with stacked filters for streams and I've realized that you can build enormous zip bombs by nesting FlateDecode filters like in this file: bomb.pdf

The file isn't actually a valid PDF file and most PDF parsers I tested recognize that without decompressing the whole content first. pypdf however tries to decompress the whole stream before parsing it. This normally works but the file I provided unpacks to over 1PB of zero bytes.

A fix for this would be to stream decompression as you can process decompressed data from zlib before you've finished decompressing the whole thing.

I'm pretty sure that this would require a significant amount of changes to the decompression logic but this could also be seen as a security flaw as parsing a small untrusted PDF file could lead to a DOS.

I'm not really sure what policy you have for these kinds of issues but I wanted to report it in case someone might want to fix it.

[stefan6419846]

Thanks for the report.

The file isn't actually a valid PDF file and most PDF parsers I tested recognize that without decompressing the whole content first.

We would fail parsing as well - with the original reproducer and a small fix even without decompressing anything due to a violation of the specification in the cross-reference stream properties.

I'm not really sure what policy you have for these kinds of issues but I wanted to report it in case someone might want to fix it.

GitHub shows you a security tab and the security policy in the details on the right when opening the repository. Additionally, when choosing the issue type, there is a dedicated entry for (possible) security issues.

A fix for this would be to stream decompression as you can process decompressed data from zlib before you've finished decompressing the whole thing.

I'm pretty sure that this would require a significant amount of changes to the decompression logic but this could also be seen as a security flaw as parsing a small untrusted PDF file could lead to a DOS.

As mentioned by you, there is no direct way to fix this issue without more work. Given that you immediately went public with your report, we have to focus on short-term mitigations for now. This is mostly based on a (user-configurable) limit for the decompression process of zlib.

I will try to push a fix as soon as possible and issue a new release, which will be the major release initially planned for in a about a month.