Prevention of stamp attacks on PDFs

[eduperottoni]

Hi, @MatthiasValvekens!

I was thinking about the attack that can occur in a PDF document when a malicious stamp is inserted in the document. This stamp may have the size of the entire page and replace the real content of the page, deceiving who read this document. Obviously some PDF readers implement features in order to show every revision of the document, wich allows the users to see when the document was maliciously modified, but most of them don't (like browsers).

Reading ISO-32000, I couldn't find a way to prevent this kind of attack. In the application I'm working on, the ideia was to prepare some signature fields, with append_signature_fields API function and then disable signature fields creation or any other modifications in the document through a certification signature. But, at this point, if I close the document with NO_CHANGES, I can't perform signatures in the fields I've created earlier. Although, if I use the level 2 of modification (FILL_FORMS), I can't avoid new signature fields creation (in other applications, for example) and consequently can't prevent the mentioned attack.

Is there a way to prevent this kind of attack in PDF? Or is there any alternative way to get close to this prevention?

Thanks!

[MatthiasValvekens]

Hi @eduperottoni,

You are on to something :). This is a known issue, and largely due to the fact that DocMDP validation is an extremely nebulous notion that is interpreted differently by various vendors, and even the de-facto "reference implementation" in Acrobat is a moving target in this regard.

Of course disallowing page content modifications (duh) and non-signature annotations is easy enough, but there's no interoperable way of preventing new signature fields from being added (other than NO_CHANGES, and even in that case one arguably needs to allow invisible signature fields for PAdES-related reasons). In practice, attacks of the kind you describe are trivial to detect by a human expert, but there's no universally agreed-upon way of automating that.

In general, you can essentially either have cryptographically sound multi-signer workflows or allow signatures to be visually part of the document, but not both. The business world has chosen to prioritise the latter, and seems to have settled for a "well, if push comes to shove, the forgery will be easy to detect in a court of law" kind of approach when it comes to form filling in signed documents. (I've seen that argument play out with, erm, shall we say, "various degrees of civility" at industry conferences ;) )

A couple of years ago (while I still worked for iText) I wrote a few words on the subject: https://itextpdf.com/blog/itext-news-technical-notes/attacks-pdf-certification-and-what-you-can-do-about-them. The status quo hasn't really changed since.

[eduperottoni]

Thank you so much for your answer, @MatthiasValvekens! I read your post from iText and it's so interesting. I also read a little about the attacks in pdf-insecurity

It's a shame we don't have possible ways in standard to even prevent or at least decrease effectiveness of this attacks without loss important features in signing-flows.

[MatthiasValvekens]

It's a matter of priorities really. Fact of the matter is that if you want iron-clad multi-user signing without any of the pitfalls of the current system, you need a solution that encapsulates signatures from the source document. It's actually not that hard to set something like that up in PDF by making clever use of embedded files, but applying that to signature workflows essentially requires giving up support for visible on-page signatures, at least in their current form.

Business users like the visual aspect, so it's difficult to motivate the PDF tech crowd to standardise a feature that abandons something people like, just because it makes validation more robust. Hell, the ratio of PDF products that support signing vs. validation is probably something like 10:1 😂 .