EldoS | Feel safer!

Software components for data protection, secure storage and transfer

PDF Signature collision

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#14245
Posted: 08/19/2010 09:24:48
by Santiago Castaño (Standard support level)
Joined: 04/16/2006
Posts: 155

Hi Eldos,

Today reading some technical news (in pcmag) i've found that a person has found that it's possible to tamper a PDF document because of "serialization". More info at: http://pdfsig-collision.florz.de/

As i've read it i think it's because of the implementation of the standard in PDF signatures and i want to inform you about this issue to keep an eye if the standard gets fixed to fix also SBB implementation asap, as i suppose that SBB today will not protect us against this issue?

Regards
#14247
Posted: 08/19/2010 23:37:14
by Ken Ivanov (EldoS Corp.)

Santiago, thank you for getting to us with this. It was of a great interest for us to read about the attack and its idea.

As a matter of fact, the flaw in the PDF standard does not allow to tamper an arbitrary signed PDF document. Instead, it allows to create a document with two different contents (say, one "visible" to the signer and another one "hidden"), make the signer sign the "visible" content, and then substitute it with the "hidden" one without invalidating the signature. I should note that signing should be performed with special software that "knows" about the flaw and the "Janus" feature of the document, and can sign it in the proper way to make content substitution possible in the future.

SBB is not a subject for this flaw (neither Acrobat is), as it always adds its own signature block to the end of the document. I.e., even if the attacker prepares a "Janus" document, SBB will ignore the preliminary signature placeholders and add its own signature block which does not allow content substitution.
#14251
Posted: 08/20/2010 03:17:29
by Santiago Castaño (Standard support level)
Joined: 04/16/2006
Posts: 155

I'm glad it's not that harmful i've thought it was :).

So the "problem" is only while verifying PDF's, we'll verify those "janus" documents and verify them as OK and we cannot do anything against this i suppose, but anyways at least we're not the generators of that PDF file.

I understand better your words how it works, but this phrase made me a question:

Quote

SBB is not a subject for this flaw (neither Acrobat is), as it always adds its own signature block to the end of the document. I.e., even if the attacker prepares a "Janus" document, SBB will ignore the preliminary signature placeholders and add its own signature block which does not allow content substitution.


Is this also true when we have EmptySignatureFieldCount>0 and add the signature into one of the empty signature placeholders? reading your words seems like we're not affected also, just a re-confirmation in this scenario -a document prepared with empty signature holders that can make this flaw-
#14257
Posted: 08/20/2010 09:21:17
by Ken Ivanov (EldoS Corp.)

Quote
So the "problem" is only while verifying PDF's, we'll verify those "janus" documents and verify them as OK and we cannot do anything against this i suppose, but anyways at least we're not the generators of that PDF file.

Yes, exactly. Detecting such documents is more a heuristic task and implementing it correctly is quite challenging.

Quote
Is this also true when we have EmptySignatureFieldCount>0 and add the signature into one of the empty signature placeholders?

Yes. Though they are called "empty signature fields", they are not placeholders in physical sense (big areas of empty space within the document), and the signature value is written to the end of the document anyway.

Reply

Statistics

Topic viewed 874 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!