According to an article published last week, it is apparently possible to construct a signed PDF that can have its underlying data changed such that the signature is still valid, but the presentation of the data is changed.  It’s a neat trick, but there are a few things that mitigate the risk inherent in the vulnerability:

  1. The signature has to be applied to a carefully crafted PDF file.   A PDF file that you create and sign is unaffected by this attack;  if you examine the data within the file, the presentation data for both the “recommendation” and “order” documents is present in both.  Obviously, you will not be adding rogue data into your own PDFs before signing them.
  2. As stated in the article, it’s not really clear that the PDFs used in the proof of concept are syntactically valid PDF files.  However, Acrobat does open and display them as the attack intends, so that may be irrelevant.  Although, an Acrobat security update could fix the issue if this is the case.
  3. It appears as though, by looking at the proof of concept documents, that the special construction of the PDF requires precise byte positioning in the file for the various objects used in the attack.  It is not mentioned in the article, but it may not be true that such a document can be constructed with a blank signature field that can be signed in Acrobat and subsequently attacked using this method.

It will be interesting to see what, if any, response Adobe has to this publication.  I know my way around the PDF standard (as it pertains to digital signatures) fairly well, but I’m by no means an expert.  It seems to me, though, that this attack requires several things, including the execution of the initial digital signature, to be performed in a precise way, which may mitigate the risk of the attack working in a real-world scenario.

3 thoughts on “PDF Signature Vulnerability Found (Kind of)

  1. foo says:

    Your reasoning is pretty flawed, logically. The most obvious one: “Although, an Acrobat security update could fix the issue if this is the case.” As the deficiency is in the specification, Adobe cannot fix it with a “security update.”

  2. Walt says:

    If it’s a syntactically invalid PDF that Acrobat is displaying without problems (using the “strict in what you create, lazy in what you accept” parsing theory), then yes a security update that views such a PDF as invalid would “fix” it – not the underlying issue, but at least the presentation of invalid PDF data. This point hinges on whether or not the PDF in the example is syntactically okay – I don’t know enough about the PDF standard to comment on whether or not this is the case.

  3. foo says:

    Well, I guess I did maybe slightly misrepresent your argument, so let me clarify: It’s not just unclear whether the PoC is syntactically invalid, but rather this most likely (AFAICS) can not be decided on the basis of the specification. Plus, even if it could be shown to be syntactically invalid, you’d still have to prove that there is no other syntactically valid way.

    So, most likely the spec is at fault either way – either the specification of the syntax is lacking or the signature stuff itself is broken, possibly a mixture of both. Therefore, no security update possible (most likely) …

Comments are closed.