Contents

• Introduction
• PDF File Format
• Attacks Highlighted by 'pdf-insecurity'

Introduction

A recent analysis of several PDF signature vulnerabilities (https://pdf-insecurity.org) shows that many PDF viewers are susceptible to attacks. In particular, the authors highlight a false Amazon invoice reported as 'Document has not been modified since the signature was applied' by Adobe Acrobat DC.

SecureBlackbox is not vulnerable to these attacks. SecureBlackbox's secure, rock-solid components protect your documents from these attacks, as well as many others.

Most of the weaknesses of the PDF format are well known, and proper care has been taken to withstand all of them. Below, we briefly describe the attacks mentioned on the pdf-insecurity site and explain how SecureBlackbox addresses them.

PDF File Format

The PDF format supports incremental updates, where changes to the document are recorded as a set of modifications of the baseline revision. A document may contain a number of revisions with different creation times, separated by the %EOF trailer. While this is generally a handy feature, it introduces some complications to signature validation.

A PDF signature covers a certain revision of the document, and certifies only that revision. Each signature contains information about the byte range in the file it covers. However, nothing prevents someone from editing a signed document by utilizing the incremental update feature. If such modifications are made, the signature remains valid (as the revision it covers is intact), but the document may look completely different due to the changes made.

Therefore, a typical validating application should be aware of this feature and handle it in accordance with its use scenarios. In many situations, it would be enough to check if the last/only signature covers the whole document, and let the user know that a particular signature covers only a certain revision of the document - but not any succeeding changes. SecureBlackbox users can extract the signed version using the PDFVerifier component and calling the GetSignedVersion method.

Attacks Highlighted by 'pdf-insecurity'

1. The Universal Signature Forgery (USF) attack attempts to corrupt the signature information in order to disable (at least some parts of) the verification process amid hopes the PDF viewer will treat the signature as valid. In SecureBlackbox, the corresponding byte ranges are validated in the GetSignedVersion method among primary checks of the signature. Any issues with signature contents and/or formatting are further verified by lower-level CMS and PKCS#7 components (which are not forgiving with regard to any signature format violations).
2. The Incremental Saving Attack (ISA) introduces a new post-signature revision of the document via incremental updates. This is also mitigated within GetSignedVersion. Generally, a call to GetSignedVersion provides you the full signed copy of the document, cutting off anything besides the byte ranges, and making sure that the byte ranges cover the entire document apart from the signature body itself (exclusively). Any changes invalidating the integrity of the document, such as omitted trailer or xref tables, are detected when the document is loaded.
3. The Signature Wrapping Attack (SWA) manipulates the document by changing the visual representation of the document (in a post-signed revision) and inserting false data (e.g., %EOF) in the signed revisions. This is also covered by byte range checks in GetSignedVersion. In this case, the body of the signature is not the only object excluded from the byte ranges, so the component will report this via an exception.

In addition to the described signature vulnerabilities, SecureBlackbox is protected from encryption attacks, as it processes encrypted documents passively (in terms of the pdf-insecurity authors, it lacks the 'exfiltration channel') - i.e., it does not process interactive forms or follow hyperlinks.