How can i prevent Universal Signature Forgery (USF) , Incremental Saving Attack (ISA), Signature Wrapping (SWA) in Apache PDFBox

Question

Currently Iam creating a digital and electronic signature using apache pdfbox. Recently i came to know the vulnerabilities in digital and electronic signature like Universal Signature Forgery (USF), Incremental Saving Attack (ISA) and Signature Wrapping (SWA). Does PDFBox takes this care automatically or do we need to enforce additionally in code to take care of this

Answer 1

On the attacks themselves

To start with, the attacks mentioned have been developed in a master thesis ("Security of PDF Signatures" by Karsten Meyer zu Selhausen at the Ruhr-Universität Bochum) publicly made available in February 2019. A pre-release of the derived "Vulnerability Report" has been shared and discussed with a number of information security related organizations in November 2018, so a number of the PDF signature validators tested in the paper meanwhile have been fixed to properly show a signature validity violation or restriction. You can find an overview on the PDF insecurity site.

Reading the thesis and inspecting the examples I got the impression that the author and his advisers have not yet dealt with PDFs for very long, at least not in depth. Two examples of what caused this impression:

• The thesis explicitly is based upon the PDF Reference 1.7, published 2006, it is aware of PDF having become an ISO standard in 2008 (ISO 32000-1) which meanwhile, in 2017, has been updated (ISO 32000-2).

  The effect is that certain aspects in it simply are outdated. E.g.

  • It describes as a topic for future work "Attacks against object digests" but object digests have not been included in the ISO 32000-1 standard in 2008, they have been obsolete for more than 10 years now at the time of the publishing of the thesis.
  • Furthermore, the "Vulnerability Report" derived from the thesis contains a proposal for an improved verification but mentions as drawback that it requires a change in the PDF specification which defines ByteRange as an optional parameter... but it has been required since 2008 in ISO 32000-1 (at least for the signatures of interest here)!

• The manipulations (foremost in the context of the USF attacks) were done without adequate respect for the validity of the resulting PDFs.

  A visible effect is e.g. that after opening the test PDFs in Adobe Reader, closing it again causes the viewer to ask whether it should save the changes, i.e. the repairs to the file the viewer had to apply to make it valid enough for the viewer to display it properly. On one hand this behavior can make a user wary of manipulations, and on the other hand these repairs by themselves can already invalidate a signature making a probably good attack fail.

  For some attack scenarios invalid PDFs are ok, maybe even productive, but in many scenarios they are unnecessary and should be avoided.

Nonetheless the attacks are interesting, in particular they make me wonder what attacks might be devised by attackers who do have a more in-depth knowledge of PDFs...

Preventing upcoming attacks as a PDFBox based signer

The OP is "creating a digital and electronic signature using apache pdfbox" and in respect to the attacks above wonders what he as a signature creator can do to prevent attacks.

There actually is little the signature creator can do to prevent the attacks, it mostly is the job of the signature validator to recognize manipulations.

In one way, though, he can help: Some variants of the signature wrapping attack use the area of the trailing string of 00 bytes in the signature content; so he can help prevent some attacks by keeping that string as short as possible. Unfortunately there are numerous signing setups in which one can hardly predict the size of the signature container to embed here, so a certain number of trailing 00 bytes can hardly be avoided.

Additionally you can make your signatures certification signatures with "no changes allowed" - validators which respect the certification level this way more easily can recognize and report any changes as disallowed. This might be a bit of a hindrance, though, if used in the context of Long Term Validation extensions.

Correctly recognizing attacks as a PDFBox based validator

First of all, PDFBox does not provide a ready-to-use utility that checks the kind of changes made in an incremental update. Unless you implement that yourself, therefore, your validator can say only for signatures covering the whole document that they sign what the file shows. For previous signatures it can merely say that the respective signature signed some earlier revision of the document but not whether or not that revision corresponds to the current revision anyhow.

A PDFBox based validator (without a large own contribution for revision comparison) in its report for a signature not covering the whole document must indicate this fact and ask the user to determine the changes between revisions manually.

Running the PDFBox signature validation example ShowSignature against the sample attack files from the PDF security site (here), one gets the following results:

• Very often (most ISA, all SWA files) one sees an output of "Signature verified" together with "Signature does not cover whole document".
• In one ISA case there is a NoSuchAlgorithmException.
• Often (most USF files) there is a NullPointerException.
• In one USF case there is a ClassCastException.
• In one USF case there is a CMSException.

(Result of the SecurityThesisValidation test)

Thus, as long as a PDFBox based validator correctly outputs the "Signature does not cover whole document" warning where applicable and outputs a "Failure" or "Unknown" in case of arbitrary exceptions, it does not fall prey to the present attack files.

As @Tilman also said in a comment to the question, deactivating lenient mode when loading PDFs for validation might be a good idea. That would catch most ISA and some USF attacks already before any validation routines could be fooled...

---

Beware, though: As mentioned above the thesis and the example files show some deficiencies. Thus, there is a chance that PDFBox is susceptible to improved versions of the attacks. In particular the signature wrapping approach looks promising as PDFBox uses the Contents string only and does not compare it to the contents of the byte ranges gap.