Five months ago, we announced the release of trailblazing features for digital signing workflows. Realizing developers needed a digital signature solution they could trust, we introduced a secure-by-default approach to validation and Modification Detection and Prevention (MDP).

These capabilities enable developers to safely build interactive user experiences with their signing solutions, including support for form filling and multiple signatures, without invalidating previous signatures.

Since announcing these features, customers have brought to our attention an academic report by authors Mainka, Mladenov, Rohlmann, and Schwenk last year detailing several ways to bypass digital signature validation in PDF.

If you're using the PDFTron SDK today for validation or are considering its use down the road -- rest assured. You're protected. And in this article, we discuss how and drill into specific vulnerabilities disclosed in the report.

linkBackground

In their March 2020 report, titled "Vulnerability Report: Attacks Bypassing the Signature Validation in PDF," the research team of Mainka et al. revealed a series of vulnerabilities in PDF-based digital signatures.

Cited in the report is a previous 2019 analysis of 22 commercial applications. This found 21 vulnerable to one or more of three severe weaknesses in PDF-based digital signature validation published at https://pdf-insecurity.org/. The March 2020 study demonstrates how attackers can exploit these weaknesses to change document appearances or add vulnerabilities -- and still have manipulated content pass validation.

At the inception of our signature validation solution, we took the possibility of such weaknesses very seriously. At the same time, we didn’t want to limit what developers could do with our technology. Thus we built our validation and Modification Detection and Prevention (MDP) verification from the ground up using a different and more strenuous approach. We call this approach "secure by default”, detailed in a lengthy September 2020 article on our blog.

Summarized quickly: secure by default is an approach whereby the PDFTron SDK disallows every change upfront and then only allows changes back in selectively based on a list of safe actions curated by our engineers. Such a "strong" approach to verification and MDP ensures less uncertainty third parties could prospect for weaknesses, such as those published on pdf-insecurity.org.

In contrast, many other vendors don't bother with MDP verification. They instead leave it to the customer. Or they support MDP but take an easier-to-implement and permissive approach, restricting only known dicey actions while ignoring other actions deemed not worth investigating.

linkPutting PDFTron to the Test

We looked at vulnerabilities discovered by researchers and at the associated test corpus available at pdf-insecurity.org. And after careful evaluation, we determined the PDFTron SDK not vulnerable (and never was vulnerable) to any of these weaknesses.

Under our secure-by-default design, an attacker shouldn't be able to change random referenced objects arbitrarily. This prevents (among other things) document structure attacks reliant on modifying objects such as Pages, Page, Catalog, and Contents within a PDF document.

linkRegarding Specific Vulnerabilities

Here is a detailed account of vulnerabilities discussed by Mainka et al. and how they are solved with the PDFTron SDK.

linkVulnerabilities in Section 5.3

link1. Hiding page content via incremental saves

The first vulnerability referenced in the report consists of hiding page content by changing Page objects via PDF’s incremental save feature (see section 2.2.7 "Incremental Update" in the PDF Reference Manual). Using incremental save, a third-party could insert new content or changes by writing to the end of the file, outside the encrypted envelope created with the signature digest.

The PDFTron SDK MDP verification is not vulnerable to the first item. An attacker is not allowed to create or modify pages without detection under our MDP design. Any violation of these privileges would invalidate signatures.

link2. Changing the overlay from an image to Metadata

A second vulnerability consists of changing the type of an overlay from an image to Metadata. For example, suppose a validator program detects changes by looking at object types, and object types are changed so they no longer fall into categories screened for changes. In that case, a reader program will fail to detect modifications.

Additionally, a reader program that decides whether to display overlays based on object type will no longer display important information during review and signing. But the document may be changeable later (under the nose of a less-strict MDP verifier) by changing the object type to display previously hidden content.Thus the signer would have authorized content they never saw!

The PDFTron SDK is not vulnerable here either. It disallows changes to referenced objects with no reason to change, so the image object will be detected as a change to an existing object and disallowed.

linkVulnerabilities in section 5.4:

link1. Changing objects referenced by a Field Dictionary

This vulnerability involves changing objects referenced by a Field dictionary (e.g. BBox). PDFTron SDK is not vulnerable as it only allows AP, sometimes flags, and V to change on fields in incremental saves (for signing additional signatures), if allowed by the permissions.

link2. Adding or changing fonts

Another vulnerability consists of adding or changing fonts, on the assumption that verifiers won’t check this. The PDFTron SDK does not allow any referenced objects to change except if required by a PDF workflow and allowed by permissions.

linkFurther Considerations on Section 5

The PDFTron SDK is not vulnerable to vulnerabilities described in section 5 as each requires modification of the reference to the document catalog dictionary (Root) from the trailer. We will detect this change. And you can entirely mitigate these attacks with the precaution of saving documents using remove_unused mode before applying the first signature with the PDFTron SDK as follows:

// You have an unsigned document. You save with e_remove_unused to clean it up of shadow (unreferenced) objects before saving.
doc.Save(output_path + "tiger_withApprovalField_output.pdf", SDFDoc::e_remove_unused, 0);
// Now, you can sign the document more securely.

linkConsiderations on Section 7

In section 7, the research team recommends several countermeasures to previously discussed vulnerabilities. Each involves reporting unusual changes in the save of the document.

The PDFTron SDK already has these countermeasures in place, as it flags e_invalidated_by_disallowed_changes and e_has_allowed_changes as possible codes within its MDP verification reporting.

To make it easy to find which of or if any changes are unsigned, we also offer an API to fetch the ByteRanges to which a signature applies:

const std::vector<Common::ByteRange> byteranges = digsigfield.GetByteRanges();
    // Caller is responsible for sanity-checking the byteranges before using them...
    if (byteranges.size() != 2)
    {
    throw std::exception();
    }
    // ...

linkOther Advanced Considerations

In addition, the group of researchers also described a signature wrapping attack, as outlined in older articles and in the test corpus at pdf-insecurity.org. The PDFTron SDK is not vulnerable to the wrapping attack during verification with documents signed with the PDFTron SDK.

The reason for this is as follows: the attack consists of adding another ByteRange inside the padding after the CMS in the Contents entry of the digital signature dictionary. This technique may cause alternatives to verify a modified signature against a different range of bytes.

However, with the PDFTron SDK, we only use the first ByteRange entry found, and if you use our signing, the ByteRange will be written before Contents. The PDFTron SDK signing also mitigates any possible wrapping vulnerability in other validators because we put less padding after CMS (only 64 bytes) than many other processors (which add as much as 10 MiB). We thus make it difficult to put anything significant after the CMS data.

Finally, regarding the class of “universal signature forgery” attacks described earlier by the same research group: the PDFTron SDK is not vulnerable to those either, representing a large portion of their test corpus to which we are not vulnerable, as mentioned above. These attacks consist of the introduction of various edge case or illegal values into signature dictionaries, which we check for rigorously and disallow in our secure-by-default verification code.

linkConclusion

We hope this article directly addresses the concerns you may have regarding the security of our digital signing technology.

If you have any questions or concerns, please contact us and the developers who built our signature technology would be happy to discuss them with you.