#6 CVE-2018-5296 - uncontrolled memory allocation in the PdfParser::ReadXRefSubsection

[Mattia Rizzolo]

https://security-tracker.debian.org/tracker/CVE-2018-5296

In PoDoFo 0.9.5, there is an uncontrolled memory allocation in the PdfParser::ReadXRefSubsection function (base/PdfParser.cpp). Remote attackers could leverage this vulnerability to cause a denial-of-service via a crafted pdf file.

[MarkR]

The problem is m_offsets.resize(nFirstObject+nNumObjects) in PdfParser::ReadXRefSubsection, and also m_offsets.resize(m_nNumObjects) in PdfParser::ReadDocumentStructure()

Looking at the PDF spec Table C:1 in Appendix C:2 of 32000:2008 says the maximum number of indirect objects allowed in a PDF file is 8,388,607

If the max value passed to resize() was restricted to 8,388,607, then this would restrict the allocation to:

8,388,607 * sizeof(PoDoFo::PdfParser::TXRefEntry)
32-bit: 8,388,607 * 16 = 134 MB
64-bit: 8,388,607 * 24 = 201 MB

[Dominik Seichter]

Quoting from the specification: "Table C.1 describes the architectural limits for Acrobat viewer applications running on 32-bit machines.". So, I was wondering if this is still the case for 64bit Acrobat Reader, but it seems the rule is still applied and even part of PDF-A/2 and PDF-A/3 validation rules (see Rule 6.1.13-7 at http://docs.verapdf.org/validation/pdfa-parts-2-and-3/).

Also the unofficial version of the ISO standard claims, that writer shall create PDF files that can be read by 32bit applications: https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf (see page 649): "Because conforming readers may be subject to these limits, conforming writers
producing PDF files should remain within them. "

So, I think it is fine to apply this limit. Done in revision 1925. By this, I think this issue can be closed. Please let me know if there is still something to do here!

[Dominik Seichter]

See previous comment.