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.)
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:
- 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.
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).