#15 CVE-2018-8002 - Stack overflow when reading deep nested arrays

[Mattia Rizzolo]

https://security-tracker.debian.org/tracker/CVE-2018-8002
PoC https://bugzilla.redhat.com/show_bug.cgi?id=1548930

In PoDoFo 0.9.5, there exists an infinite loop vulnerability in PdfParserObject::ParseFileComplete() in PdfParserObject.cpp which may result in stack overflow. Remote attackers could leverage this vulnerability to cause a denial-of-service or possibly unspecified other impact via a crafted pdf file.

[zyx]

This requires changing the way the nested types, namely arrays here, are loaded. Using callstack for it is wrong, because it can cause stack overflow due to recursion. Fixing this requies a significant change in PoDoFo, I'm afraid. I do not have any fix (or a concrete idea) for the fix, though I'd probably not suggest doing any such significant change in the sources just before the planned release.

[zyx]

As a proof of concept, when I edit the file and shorten the nested arrays PoDoFo can open it and throws its own exception, instead of crashing on stack overflow.

[MarkR]

Couldn't the stack overflow be prevented using the PdfRecursionGuard patch?

All that's needed to add this is:
a) moving the PdfRecursionGuard class in my patch to an .h file
b) adding an m_nRecursionGuard member to PdfTokenizer initialized to 0 in constructor
c) adding the line PdfRecursionGuard guard(m_nRecursionGuard) to the recursive functions that appear in the callstack

[zyx]

It would be only to workaround the issue. As the standard allows nested arrays, then the nesting level can be huge, while still providing properly formatted PDF, in contrast of improperly formatted PDF with circular dependencies in XRef tables or such.

[MarkR]

Yes, I agree but I think these are two different (but related) issues

(a) Preventing all recursive stack overflows because very bad things can happen in some environments (e.g. https://googleprojectzero.blogspot.co.uk/2016/06/exploiting-recursion-in-linux-kernel_20.html)

(b) Allowing deeply nested arrays in PDF documents. This is part of larger problem related to the lack of architectural limits in the PDF format - it's possible to have well-formed documents that won't load in some software due to internal limits (e.g. the 8,388,607 indirect object limit in Adobe Acrobat). It's definitely possible to create valid PDF documents that require more memory than can be allocated on any current hardware. (The same is true of HTML and XML as well)

There's a similar problem in XML libraries because XML allows any depth of nesting. Here's a nearly identical CVE in libxml2 which describes the issue as "does not properly keep track of the recursion depth":
https://www.cvedetails.com/cve/CVE-2016-3705/

Fixing (a) seems essential because the overflows can be exploited on some systems. Fixing (b) would be nice but can happen after (a)