2

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

Vimal Gunasekaran
  • 21
  • 2
  • For anyone not aware of these terms, have a look at the [PDF insecurity site](https://pdf-insecurity.org/). – mkl Mar 07 '19 at 17:47
  • *The basic idea of the attacks contained in the attack class “Signature Exclusion”* (aka USF) *is to confuse the signature verification logics and the information displaying logics of PDF processing applications.* Thus, chances are that PDFBox will not per se return a positive validation result but it might e.g. return an exception you (as caller of the PDFBox validation code) did not expect and, therefore, process inadequately resulting in a wrong or misleading presentation of the validation result. – mkl Mar 07 '19 at 18:04
  • Reading the papers is on my todo list… I did try many of the exploits but never got a positive result, if one includes the "Signature covers whole document" check. What I also intend to do is to remove lenient mode for signature checking when opening a PDF file. – Tilman Hausherr Mar 07 '19 at 19:37
  • Your question is sortof "wrong" because these attacks habe nothing to do with signature creation, only with signature checking. – Tilman Hausherr Mar 07 '19 at 19:39
  • @Tilman Maybe I'm a bit blind but I couldn't find a dedicated PDFBox signature validation example. If I overlooked it, can you please leave a pointer? If there is none, the question here is moot: Without such an example setting a best practice one cannot say whether or not PDFBox is susceptible to one of these faux signature techniques. (I found `AddValidationInformation` but that merely adds VRI to a signed document but it does not return any kind of validation result.) – mkl Mar 08 '19 at 08:46
  • 1
    Ah, `ShowSignature` does a certain amount of validation and outputs validation results. – mkl Mar 08 '19 at 09:06
  • @Vimal Do you have an questions about my answer? Do you need additional information? – mkl Mar 11 '19 at 17:39

1 Answers1

5

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.

mkl
  • 90,588
  • 15
  • 125
  • 265
  • "... does not compare it to the contents of the byte ranges gap" - isn't that what we're doing here? `byteRange[1] + contentLen != byteRange[2]` – Tilman Hausherr Mar 08 '19 at 15:45
  • @Tilman Oh yes, you're right, that's at least a length check. I was thinking more along the lines of a check whether the gap contains a hex string *equal byte-by-byte* to the **Content** value. Ah, one way to trick you would be to replace the hex string value of **Content** by a literal string with the identical content. Usually that literal string will be shorter than the hex string assumed in the calculation of `contentLen`. So an attacker would have some space for mischief even if keeping the byte ranges gap length equal to the length of a hex string representation of the **Content** value. – mkl Mar 08 '19 at 16:16
  • Interesting idea. I was also thinking about comparing signedData.getEncoded() with the contents and check that the rest is 00, but what you mention is better. – Tilman Hausherr Mar 08 '19 at 16:33
  • @Tilman As an aside, using literal strings for signatures is not completely unheard-of: Adobe Acrobat usage right signature used to be so encoded... – mkl Mar 08 '19 at 16:36