Recently identified PDF digital signature vulnerabilities

On February 25, 2019, researchers from Ruhr University Bochum and Hackmanit GmbH published pdf-insecurity.org, a detailed explanation of several vulnerabilities they had identified in PDF viewers and online validation services relevant to signature validation in digitally-signed PDF documents. The vulnerabilities are pertinent only to such digitally-signed documents, and not to PDF in general.

Source: pdf-insecurity.org

These vulnerabilities identified change an already digitally-signed PDF file in ways that should trigger software to consider the signature as invalid. PDF processors that don't fully implement current standards for PDF or digital signature validation, or attempt to accommodate malformed PDF files without fully considering the risks, can fail to spot these malicious changes.

In keeping with their good intentions, the researchers report that they notified a wide range of developers before publishing the details of these vulnerabilities and that patches were implemented before the research was disclosed. This post is intended to help ensure that the community is aware of the issue and to support all PDF developers in understanding how to identify and fix their software.

Use appropriate standards appropriately

The vulnerabilities identified in PDF software highlight the need for greater adoption of current standards and best practices in validating digital signatures. Following best practice is optimal, because it allows implementers to build highly capable and secure software without themselves becoming expert in every conceivable attack vector.

All these approaches rely on the tendency of PDF processors - especially interactive viewers - to accommodate malformed or broken PDF files. For marketplace reasons, it is admittedly very difficult for these developers to blindly refuse to process a PDF file that appears to include small syntax errors. But if they do choose to so process a file, then adequate measures - such as close adherence to relevant digital signature standards and a good understanding of secure software design - become vital.

PDF is a file format, not a digital signature implementation specification.

In their detailed report and paper, the researchers identified three types of vulnerabilities, briefly summarized in this post. They also propose a countermeasure algorithm.

Universal Signature Forgery (USF)

The researchers identified 24 vectors for tampering of the digital signature object within a PDF file which is then able to fool some signature verification algorithms.

It might seem that the inability to correctly read a fully valid digital signature object from a PDF file should be categorically treated as functionally equivalent to a missing or invalid signature, but it seems that not all implementations have taken this approach. As the researchers’ state in the conclusion of their paper:

“...there can be merely programming mistakes that break the whole cryptography. In the case of USF, an unexpected missing of mandatory information leads to a valid signature."

MITIGATION: This approach does not work on processors that closely adhere to PAdES standards (the technical basis of the EU-wide eIDAS framework) combined with avoiding error tolerant behavior when validating PDF signature objects.

Incremental Saving Attack (ISA)

PDF technology includes the ability to incrementally save changes to a document. The four variants of this vulnerability leverage this feature to "trick" an unaware processor into excluding malicious update data from consideration of the signature. The result is that an apparently-valid signature is simply ignorant of the malicious changes and reports the digital signature as valid.

MITIGATION: This approach does not work on PAdES-conforming processors that ensure incremental saves are correctly accounted-for when validating digital signatures, a clear best practice, and that do not permit error tolerant behavior when processing PDF signature objects.

Signature Wrapping Attack (SWA)

The SWA introduces yet another way to work around the signature, by inserting a malicious xref table in concert with a ByteRange manipulation to fool a PDF processor into believing that the signature validates the newly added data. This approach also requires zero-padding bytes in the Contents parameter of original digitally-signed PDF file and results in malformed PDF. Nonetheless, many processors will process it anyhow.

MITIGATION: This approach does not work on processors that correctly implement PAdES standards for digital signatures.

A recipe, not a guide

PDF interfaces with many complex 3rd party technologies. For digital signatures, as in many other areas, the file format specification does not define implementation details. The ISO working group that develops PDF has consistently left such matters to the appropriate experts in other groups (i.e., those managing digital signature standards such as ETSI).

PDF/A-2 and subsequent parts require that the ByteRange entry cover the entire document (excluding the signature).

PDF 2.0 explicitly aligns PDF technology with ETSI standards.

"The PDF specification"

On page 16, the researcher's report references Adobe's PDF 1.7, first published in 2006 as "the PDF specification":

"Specifying the algorithm in Listing 4.1 requires a change in the PDF specification which defines ByteRange as an optional parameter[? , Section 8.7]."

In fact, the ByteRange entry for digital signatures has always been required in all versions of the PDF specification. It's important to note that, based on the section number, the version of the PDF specification the researchers are referencing is PDF 1.7 (2006) or earlier. The research ignores the subsequent ISO standardized versions of this specification in 2008 (ISO 32000-1) and 2017 ISO 32000-2 (PDF 2.0).

As always in software development, the referencing of the most current applicable standards and industry best practices is crucial. As Munich-based PDFlib's Thomas Merz says:

"Identifying bugs in security-related software is always a good thing. However, the researchers don't take into account that the PAdES standards define additional requirements for PDF signatures on top of ISO 32000 to make signatures more secure.

For example, the PAdES standard (ETSI EN 319 142) explicitly mandates that the Contents and ByteRange entries must be present, and that "The ByteRange shall cover the entire file, including the Signature Dictionary but excluding the PDF Signature itself."

This clause thwarts the attacks if the signature validation follows the PAdES standards - which apparently wasn't the case for many validators."

Looking ahead

In light of this research, and as best practice, implementers should always look to the latest PDF specifications (currently ISO 32000-2:2017), as well as review their error-tolerant behavior in any and all security-oriented algorithms.

The researchers acknowledge that many software publishers have already pro-actively updated their implementations to address the vulnerabilities described earlier. Security is of vital importance in the PDF ecosystem, and the response to this report demonstrates a dynamic, responsive industry.

Given the significance of digital signature validation in the workflows that use them, implementers must consider that developing or maintaining support for these features entails a responsibility to look beyond the PDF specification for wisdom in handling digital signatures.

The PDF Association hosts technical working group (TWG) forums for its members. These provide advice, support and expertise to help implementers fully understand and address technical concerns. Learn more about membership benefits, and consider joining the PDF Association.

Peter Wyatt is an independent technology consultant and developer/researcher who has been actively working on PDF technologies for more than 17 years. He represents Australia as both Head of Delegation and a Subject Matter Expert at all ISO committees that define PDF standards (ISO TC 171 and ISO TC 130). Peter is currently Project Co-Leader of ISO 32000 (the core …

We use cookies to make our websites more user-friendly and to help us understand how they are used. This helps us to continuously improve the content, navigation and services we offer to site visitors. Our cookies are only used for these purposes, and only if you consent by clicking on "Agreed". You may also continue without cookies.