Attacks on PDF certification, and what you can do about them

Friday, July 23, 2021 - 13:13

In May 2021, a group of researchers at the Ruhr University Bochum (RUB) published an IEEE symposium paper on problems with certification signatures in PDF. The authors’ findings are summarized on the PDF Insecurity website. Since iText’s products are often used as part of digital signing workflows (including to create certification signatures), we felt compelled to comment. In this blog post, we’ll take you through some background on these new attacks, and explain what you can do about them.

In May 2021, a group of researchers at the Ruhr University Bochum (RUB) published an IEEE symposium paper on problems with certification signatures in PDF. The authors’ findings are summarized on the PDF Insecurity website.

Since iText’s products are often used as part of digital signing workflows (including to create certification signatures), we felt compelled to comment.

In this article, we’ll take you through some background on these new attacks, and explain what you can do about them.

Background and scope of the exploits

Besides “regular” digital signatures, PDF also allows so-called certification signatures. Cryptographically, those are no different: from a mathematical point of view, a regular signature and a certification signature are equally secure. However, the way PDF stores and interprets these signatures is special:

  • A certification signature must be the first signature in the document. As such, it is often created by the document author, and there can be at most one in any given document.
  • A certification signature contains instructions explaining what changes are allowed after signing.
  • If the certification signature allows it, the document may contain several other regular signatures in addition to the certification signature. These then function as approval signatures.

The cryptographically informed reader will ask: “But wait, what’s with all this talk about changes to the file after signing? The whole point of a digital signature is to make that impossible, right?”. That’s certainly true, but there’s a catch: PDF has an incremental update mechanism. The content of a PDF file can be changed by incrementally appending information to the file. Such updates do not change any of the signed data that was already there; in particular, incremental updates can be used in this way to add multiple digital signatures to a PDF document.

Processing these updates and judging whether or not they constitute legitimate changes is the validator’s job, and certification signatures provide some input to that process. The enforcement mechanism is contained in the signature’s DocMDP permission level. “DocMDP” stands for “Document Modification Detection and Prevention”. The DocMDP level is a number between 1 and 3 that is part of the signed data, and hence can’t be tampered with. These are the DocMDP permission levels defined in the standard:

  • Level 1: No changes allowed (with some exceptions for PAdES-related data)
  • Level 2: Signing and form filling are allowed, as is the instantiation of page templates (if the original signed revision had any)
  • Level 3: In addition to the above, comments & annotations are also allowed

The exploits that this blog post is about mostly target levels 2 and 3. They largely rely on exploiting viewer behavior and assumptions about incremental update validation. In that sense they do not really attack the PDF standard as such. PDF libraries like iText are also not directly exposed.

However, one could argue that that obscures the real problem: the PDF standard doesn’t contain any precise validation requirements for incremental updates; the vague guidance provided by the DocMDP levels is all viewers have to go on. The inevitable consequence of that is that every implementer interprets the rules in their own way. To achieve interoperability in the absence of a standard, they try to be tolerant of other implementations, which ultimately leads to attack vectors of this type. In a way, it’s another example of Postel’s law gone wrong.

There are ongoing efforts going on at ETSI and at the PDF Association to deal with issues related to DocMDP and incremental updates. Hopefully, these discoveries (and others like it) will strengthen the industry’s mandate to properly standardize incremental update validation in PDF.

The Evil Annotation Attack (EAA)

At its core, the Evil Annotation Attack is not really an exploit, since the behavior it exposes is in fact intended. Nevertheless, it serves as a good reminder for why DocMDP level 3 is dangerous, and why it should be used sparingly! In particular, you should never use DocMDP level 3 to sign a contract.

Essentially, PDF has a few annotation types that can be hard to distinguish from regular document content, such as FreeText and Stamp. Given a certified document that allows annotations to be manipulated after the fact, an attacker can significantly alter the appearance of the document that’s presented to the user.

Moreover, by cleverly manipulating some of the annotations’ metadata values, some viewers can even be tricked into rendering the annotations without listing them in the viewer’s annotation panel. This makes evil annotation attacks even easier to pull off.

You can protect your documents against this type of exploit by avoiding DocMDP level 3 in certification signatures. There are very few legitimate use cases for allowing commenting on a signed document; chances are that you’ll never need the flexibility that DocMDP level 3 provides.

The Sneaky Signature Attack (SSA)

The sneaky signature attack is a more subtle variant of the Evil Annotation Attack. To explain the underlying principle, we need to take a step back and review how PDF signatures work.

In PDF, signatures are stored in signature form fields. Form fields in PDF are bound to a particular place in the document by means of a widget annotation. The appearance stream of a widget annotation is what displays the form field on the page. Signature fields are no exception to this rule (although things get a bit murky with invisible annotations—more on those later).

Most PDF viewers will allow a signer to create their own signature field when they add a signature to an existing document. As such, most viewers will not flag such a change as suspicious if either of the following conditions are met:

  • the document does not contain a certification signature (i.e., all signatures are “regular” signatures); or
  • the document’s certification signature has a DocMDP level of at least 2.

This is perfectly fine in the vast majority of situations, but for documents with a certification signature, it ignores the fact that the original author has no control over where the new signature fields would go! In particular, by maliciously manipulating the widget annotation’s appearance stream, an attacker can mount an Evil Annotation Attack at DocMDP level 2 instead of 3 in sufficiently naive viewers. This is the essence of the Sneaky Signature Attack.

To make matters worse, some viewers don’t even require the attacker to create an actual digital signature—an empty signature field already does the trick.

If you’re producing documents with a certification signature that don’t require any subsequent modifications, setting the DocMDP level to 1 should effectively make this attack vector unexploitable. However, if your workflow does require form-filling or additional signatures by others, there’s no fool-proof way to protect yourself against this kind of attack. In the end, it’ll be up to the viewer to correctly adjudicate the changes.

Robust certification: some tips and tricks

The attacks discussed here mostly target faulty viewer behavior. As a producer of signed documents, you usually won’t be able to guarantee that your users’ PDF viewers will respond to exploits appropriately. That being said, there are a number of things that you can do to mitigate your exposure.

The section titled “VIII.B Short-term Countermeasures” in the article from the RUB researchers has some useful pointers as well, so make sure to take a look. There’s a download link on the authors’ website.

Tip 1: Choose the lowest appropriate DocMDP level for your certification signature.

It’s not uncommon to see certification signatures with DocMDP level 2 or 3 in situations where those aren’t appropriate. If your workflows don’t require documents to be updated at all after signing, simply set the DocMDP level to 1. DocMDP level 2 has its uses, but if you find yourself using DocMDP level 3 a lot, you might want to reconsider your post-signing workflow.

DocMDP level 1 should neuter both EAA and SSA exploits, and EAA can already be thwarted by DocMDP level 2.

Tip 2: Fully prepare your document before applying the certification signature

In general, you want to restrict the work that future signers/form-fillers have to do to the absolute minimum.

Taking the following precautions should help:

  • Create all form fields for future (visible) signatures before certifying the document. This makes it so that future signers never have to create new fields for a visual signature; they can just use one of the existing ones. If sufficiently many people do things the right way, validators will eventually be able to apply stricter criteria as well.
  • If your form fields require tagging, make sure that all fields are registered in the structure tree before signing. Validating updates to the structure tree is difficult and error-prone.

Tip 3: If you’re a validator, be strict by default

Attacks like these demonstrate once more that strictness in validation is a good thing. For both interactive and non-interactive validators that are capable of incremental update analysis, it arguably makes sense to—by default—forbid creating visible signature fields after a certifying signature, regardless of the DocMDP level.

There are two notable scenarios not covered by this rule of thumb:

  • Creating new invisible signature fields should always be allowed. This is necessary to support PAdES-LTA, for example. Since invisible signature fields don’t affect the presentation of the document, they’re harmless for the purposes of these attacks.
  • It’s probably also inadvisable to reject new signature fields created after a previous signature in a non-certified document. This is a matter of pragmatism: many freeware viewers only allow users to create regular, non-certifying signatures, and also don’t allow the user to create their own form fields. Being too strict on signature field creation would hurt those users.

Tip 4: If you’re a user, exercise due diligence

If you find yourself signing a PDF or validating a signature as an end user, there are a few things to be on the lookout for.

  • If you’re adding a certification signature to the document, make sure you keep the advice of Tips 1 and 2 in mind.
  • If the PDF has a certification signature already, carefully review the permission settings. If your viewer tells you something along the lines of “commenting is allowed”, that’s a red flag. Think twice before you sign!
  • When validating a PDF signature, many viewers are capable of rendering the originally signed revision, as an option in the signature panel. If you want to make sure that what you’re seeing is what the signer actually signed, don’t hesitate to make use of that feature!

Complicating matters further, some viewers (including Adobe Acrobat) display permissions for non-certification signatures in the same way as a DocMDP level 3 certification signature. This is unnecessarily confusing, but shouldn’t be cause for alarm per se. Chances are that the signer never intended it that way.

Conclusion

The Evil Annotation and Sneaky Signature Attacks cleverly exploit viewer behavior to mislead users about the content of a document with a certification signature. While the onus is on vulnerable viewers to do something about that, library creators and users can contribute to this process by following best practices. If enough signers follow suit, then validators can also afford to be more strict, which benefits everyone.

In addition to that, these exploits serve as a reminder to the PDF industry that we need to invest in the standardization of incremental update validation.

Further reading