3 ms·

It seems the issues are two fold: 1. PDF file format doesn't support a "whole document signature" as a concept. Instead, it only supports signing arbitrary fra

It seems the issues are two fold: 1. PDF file format doesn't support a "whole document signature" as a concept. Instead, it only supports signing arbitrary fragments of the document. 2. PDF tooling/software doesn't warn the user when a PDF contains some signed and some unsigned fragments. Or where fragments have been signed with different certificates. I think that is the gist of it?

deleted 8y ago
[deleted]
IgorPartola 8y ago
Correct. And #1 is a really big problem because while theoretically you could make a perfect piece of software that accounts for all fragments in current and future PDF format versions, its not likely.
dunham 8y ago
So, the document is a catalog of numbered objects. Think dictionaries and lists. The objects point to other objects and there is a table of contents near the end of the file showing where to find everything. To be backwards compatible, the signature is one of these objects. 1. It's a whole document signature, but you can't sign the signature because you don't have it yet. So you have to leave a hole for the signature data. 2. The specification for where this hole is (/ByteRange) should be in the signed data, some viewers do not appear to be verifying this. So they're sticking a fake byte range on the signature, extending the hole enough to cover said fake byte range and additional objects (modified pages) and a fake table of contents (at the original offset from beginning of the file). I'm describing one of the exploits as I understand it. To further complicate things, you can modify pdf files by appending more objects and a new TOC at the end. Think of this as append-only versioning. Historically this is used for editing (giving you a revision history) or form filling (adding the text you typed in), but it also is used to add additional signatures. (You have to add to the already signed document if you want a second person to sign it.) A signature on Version 2 of a file would encompass the entire file including the embedded Version 1 and its signature. Readers like acrobat can show you each version of file. And they can show you the version of the file as a given person signed it.

deleted 8y ago

[deleted]

IgorPartola 8y ago

Correct. And #1 is a really big problem because while theoretically you could make a perfect piece of software that accounts for all fragments in current and future PDF format versions, its not likely.

dunham 8y ago

So, the document is a catalog of numbered objects. Think dictionaries and lists. The objects point to other objects and there is a table of contents near the end of the file showing where to find everything. To be backwards compatible, the signature is one of these objects. 1. It's a whole document signature, but you can't sign the signature because you don't have it yet. So you have to leave a hole for the signature data. 2. The specification for where this hole is (/ByteRange) should be in the signed data, some viewers do not appear to be verifying this. So they're sticking a fake byte range on the signature, extending the hole enough to cover said fake byte range and additional objects (modified pages) and a fake table of contents (at the original offset from beginning of the file). I'm describing one of the exploits as I understand it. To further complicate things, you can modify pdf files by appending more objects and a new TOC at the end. Think of this as append-only versioning. Historically this is used for editing (giving you a revision history) or form filling (adding the text you typed in), but it also is used to add additional signatures. (You have to add to the already signed document if you want a second person to sign it.) A signature on Version 2 of a file would encompass the entire file including the embedded Version 1 and its signature. Readers like acrobat can show you each version of file. And they can show you the version of the file as a given person signed it.