PDF DoS

[micksola]

Note: This is an old bug post for educational purposes only. It has been fixed in latest supported versions of ClamAV.

aCaB writes:

Hi,
the "new" pdf parser in git comes with terrible complexity and no limits or mitigations of sort (in fact not even best practices like bailing out on cli_calloc's failure).
Because of that it's easy to trick pdf_extract_obj into a huge pdf_parse_dict/pdf_parse_array loop, with more heap consumed at each round.
Depending on the available system resources, it's possible to trigger the kernel OOM killer or to make clamd/clamscan crawl for several minutes on a very small file.

[Here is a proof of concept]
poc_sample.pdf

HtH,
-- aCaB

[micksola]

aCaB writes:

Hi ...,

had some time to play with this again.
Attached is a tiny patch that limits the content size of pdf dicts and arrays to that of the parent. It does fix the root cause of the O(N^2) and I didn't notice any adverse effect but I've done very little testing, so YMMV.

Note that even with the patch applied the new parser still lacks proper depth limits and will still blow up given enough recursion. A limit on pdf->nobjs should also be enforced.

Finally even with those fixes in place, at least the dict handler (and possibly the array parser) can be tricked into computing the wrong object length. That's because different rules are employed when computing the dict size and when actually parsing its contents.

Hope that helps.

pdf_dos_patch.tar.gz