Security researchers have found that it is possible to alter a digitally signed PDF without invalidating its signatures. To demonstrate it, they produced a fake document “refund order” of $1,000,000,000,000 dollars, with a valid signature from Amazon. This sparked my attention, since I was quite sure that they didn’t use some sort of quantum device to break the cryptography involved in the signing process. So what exactly is going on?

The researchers claim to found at least three different ways to, in their words:

… use an existing signed document (e.g., amazon.de invoice) and change the content of the document arbitrarily without invalidating the signatures. Thus, we can forge a document signed by invoicing@amazon.de to refund us one trillion dollars.

That’s not good news if you take into account that the main purpose of digitally signing a document is, well, prevent unauthorized changes in that document. The good news is that you can update your software to fix this flaws because of this research; the main PDF readers companies were given time to fix the issues. The bad news is that if you rely on the signature verification for any sensitive process, you likely want to go back and see if you were using vulnerable software previously and check that documents were correctly validated. I’m thinking about government institutions, banks, insurance companies and so on.

The implications are yet to be seen and probably won’t even be fully known.

There are three classes of attacks that work on different software. I’ll try to go into each one from what I could tell from reading the research.

Universal Signature Forgery (USF)

This attack works by manipulating the signature object inside the PDF file. This object contains the information needed to validate the signature and has inside, among other fields, the offsets of the bytes used to compute the hash of the signature. The hack here is to add content to an already signed PDF but to either remove this range or change it to an invalid value. The result is a PDF that has a valid signature inside but an invalid signature object. The validation logic in some of the tested software defaults to displaying that the signature is valid and drops any warnings about not being able to calculate the hash of the signature.

Incremental Saving Attack (ISA)

In its original form this is more a feature than an attack. PDF allows for incremental saving, that is, adding content to an already existing PDF file. By taking a signed PDF and adding unsigned content, the reader software should notice that the added part is not signed and present a warning. But it is possible to add content in a way that is not compliant to the PDF specification and make the reader not notice that there was content added in the first place when it comes to signature checking and still render the content on-screen.

Signature Wrapping (SWA)

This last attack is arguably the most interesting. Instead of invalidating the byte range offset as in the USF attack, the attacker manipulates a signed PDF file byte ranges field in a way that he can insert content between the signature and the end of file. This makes the software properly calculate the signature hash but it skips the added part since it was not referenced in the byte ranges.

Researchers Conclusions

From the 22 tested desktop readers and seven online validation services, all except three were vulnerable to at least one variation of these attacks. That’s around 90% so your favourite PDF reader is most likely on that list. Of course, maybe you don’t even use the signature verification directly. But your bank might.

Unfortunately, most of the reader software is closed-source, and without access to the source code of the readers, it’s harder for researchers to pinpoint what causes this wrong behaviour. From what they could figure, there are probably two main causes:

The specification is very vague about signatures and especially how to validate them.
The analysed readers are very tolerant about opening, validating and showing malformed PDF files.

It is interesting to see that, in the context of vague specifications, the same errors were being made by many different implementations and companies. The last conclusion seems a bit obvious. Fault tolerant software can be good in many situations but not in signature validation.

This is a scenario where software should definitely not be tolerant at all.