11

What are the security risks associated with PDF files?

There is, of course, the general risk associated with any type of file: that whatever application is used to read it will have a bug that can be exploited by certain byte sequences within the file, thus crashing the system, or worse, executing arbitrary code.

That's a pretty standard security issue. Anything extra on that general risk specific to PDF files?

Beyond the above general risk, what other risks are associated with PDF files?

Since PDF files can contain javascript (JS), what risks does that pose? Or is it well locked down for all major PDF viewers/editors (Adobe Reader, PDF-XChange, Sumatra, Foxit, Nitro, as well as the internal viewers in Firefox and Chrome)?

Are there other risks as well?

Do some PDF files have "call home" routines that can send a ping (or other data) to a server when they are opened or edited?

What about edit-protected PDF files or password-protected PDF files? Anything special there?

I'm most interested in answers that are relevant to Windows and Android, but am also interested in those relevant to linux, unix, OS X, and iOS, as well as OS-agnostic answers.

3
  • This is an incredibly broad question. Care to narrow it down a bit? – Mark Oct 31 '14 at 7:06
  • 2
    Well, it's specific to one single file format. That's pretty narrow when dealing with IS. I can break up the question into several different posts, but other people will complain, and the answer will become diluted across multiple posts. – RockPaperLz- Mask it or Casket Oct 31 '14 at 7:16
8

One PDF-specific risk is that Adobe and third-party reader extensions are supported: your PDF viewer may have extra modules loaded, or may require them to open certain documents. Examples include:

Both of these endeavour to constrain digital document use. At best, such features increase the attack surface, and at worst may deny you access to some of your files, report on your activity or otherwise take liberties with your privacy, documents, computer or network. (Sound familiar? Seems analogous to a browser and web page that needs Flash or a similar proprietary plugin.)

See also this question which covers PDF phone-home capability. Javascript, embedded multi-media (including, but not limited to Flash) and Xobjects (external streams) are at least some of the ways to achieve that.

Some less-obvious risks associated with, but not entirely specific to PDFs:

  • PDFs can contain attachments, though not all readers support this, and those that do don't always visually indicate their presence. These can be any type of file, including another PDF. An encrypted PDF (commonly RC4 or AES) is identifiable as a PDF (only the data streams are encrypted, rather than the file as a whole), the presence of attachments is not evident in this case. Behaviour is restricted on some platforms at least, see Adobe's KB 331371 and KB 328671. (I consider this is a potential risk because it comes as a surprise to many people, and it may be used for stealth transfer. The "Peachy" worm is a proof-of-concept example)

  • Misplaced faith in native "security features" such as no-copy, no-print, no-edit. These are effectively discretionary controls, at the discretion of the viewer software itself.

  • The structure/layout of the PDF format is quite loose, and PDF lends itself to use and abuse as a chameleon or polyglot format (PDF), see Corkami's examples here: http://code.google.com/p/corkami/wiki/mix?show=content . This show files which are simultaneously PDF, native binary executable, .jar and .html by using similar "slack" in those formats.

  • Metadata may leak information about the document origins or history. Sloppy redaction is also problem.

  • Support for rich content (multimedia via Flash, embedded fonts) and browser integration facilitate attacks on client-side software components beyond the reader/viewer itself

See the Acrobat Application Security Guide for further details.

There are two types of PDF passwords, in Adobe terminology the user and owner passwords. The user password is used for encryption, the owner password is used for discretionary access control. These may be augmented by proprietary controls via extensions.

Password protection can be secure (using RC4-128, AES-128, AES-256 with good key derivation), but RC4-40 is still supported, and Adobe fumbled the ball with the initial AES-256 implementation in Acrobat 9/PDF 1.7 by omitting iterations in the KDF:

While this allows for 256-bit AES password protected documents to open faster in Acrobat 9, it can also allow external brute-force cracking tools to attempt to guess document passwords more rapidly because fewer processor cycles are required to test each password guess.

Applies to Acrobat 9 PDF 1.7 ExtensionLevel 3 (2008), fixed in Acrobat X PDF 1.7 ExtensionLevel 8 (which became ISO PDF 2.0). You can read some background to that issue in Sin 21 of 24 Deadly Sins of Software Security. PDF version specific details can be found here: https://www.pdflib.com/pdf-knowledge-base/pdf-password-security/encryption/

In summary:

  • PDFs are feature rich, and the implementation potentially complex, both of which contribute to an increased attack surface
  • support is multi-platform and since it continues to be the de-facto document format, approaching ubiquitous, making it a popular target. ISO standardisation of PDF 2.0 furthers this.
  • PDFs provide a vector for attack payloads (Javascript, multimedia formats, fonts, arbitrary attachments) both by design, and by accident

As with Flash, I've long had concerns about Adobe Reader's approach to browser integration which can do nothing positive for the attack surface of a browser. With native browser support for PDFs this problem is shifting away from being an Acrobat issue at least.

The result of the above (combined with the near legendary bloat of the canonical PDF reader) can been seen in the CVE statistics for Acrobat/Reader (though note there are several other Acrobat/Reader variations with separate counts, and those stats stop around 2018).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.