A plugin from one manufacturer can stop a plugin from another manufacturer from:
- working correctly
- working at all
- or change what controls it enforces
PDF Plugin Vulnerabilities & Acrobat Reader Security
Plug-ins are dangerous. If you rely on plug-ins for your PDF security, then you should be aware their security may not like up to what some manufacturers claim.
“Because of the plug-in architecture of Acrobat and PDF readers, it makes PDF a less-secure platform for DRM” – ElcomSoft CEO Vladimir Katalov.
While PDF security plugins may seem convenient, they require admin rights to install and can put your protected PDF documents at risk.
Adobe DRM Plugin and PDF Plugin Security issues
In the PDF world, it is commonplace to use plugins to provide extra functionality and features. But they are known to also create security holes. The highly respected CERT organization reported the following in respect of the Adobe system:
“Be careful not to install untrusted software, including non-certified Adobe plugins (those not signed and deployed by Adobe), unless certain of the origin and integrity of such software. Unverified non-certified plugins can be removed from the plug-ins directory, and they will no longer load at startup.”
However, it is also openly admitted that ‘legitimate’ plug-ins may compromize the security of a system:
“Developers can freely write plug-ins for Adobe Acrobat. An Adobe Reader plugin requires a license agreement and an enabling key from Adobe as part of the Adobe Reader Integration Key License Agreement (IKLA). The purpose of the Reader enabling plugin architecture and IKLA is for licensing only and does not imply suitability or endorsement by Adobe of third-party plugins. The Certified Mode of both Adobe Acrobat and Adobe Reader is used to provide added assurances that only plugins provided by Adobe are compatible. All third-party plugins are restricted to non-certified mode.”
We respect the advice given by CERT, but note that if an attacker permits the loading of unverified non-certified plugins (which happens by default in all versions of Acrobat unless you specifically check a box to say otherwise) they may introduce vulnerabilities. Of course, one must assume that this is precisely what any attacker would do.
Normal users familiar with their desktop plugins can hardly be criticized for using non-certified plugins. You can hardly expect them to understand any of these arcane technical issues, still less comply with them.
There are many Adobe Reader and Acrobat plug-ins that can load (by design) only in certified mode. One example is all documents protected with “Adobe DRM” security handler (so-called eBooks).
Certified mode assures that all other plugins, loaded with those ones, have been also certified by Adobe. However, with this vulnerability, a plugin with a forged signature can perform virtually everything, including but not limited to:
Still think DRM plugins or security plug-ins are safe?
Don’t just take our word for it, if you think plugins can’t compromise your security then read what Byran Guignard, an Adobe Certified expert, has to say.
If you cannot rely on a PDF security plugin working as expected (not conflicting or circumvented by other plugins) and failing to operate when Acrobat is frequently updated, then the plugin is effectively useless.
The following white paper, Plug-ins – a source of insecurity, examines and questions the claims often made by plugin suppliers that they are secure, giving published examples of where they are not. It demonstrates why you should not purchase a document security solution that relies on plugins.
See also PDF security flaws.
And if you are forced to turn off security in Acrobat to get the PDF security plugin to work (see Fileopen Rights Manager as an example) then you are putting the security of the application and your system at risk.
Why and how plugins can compromize security
Many software product manufacturers provide customers access into their products and Adobe is no different. There are many reasons to do this, including to:
Sometimes these points of access are called APIs, and sometimes they are called plug-ins. What do they do?
Well, they allow outsiders a degree of access to what is happening inside a manufacturer’s product by making information available, such as where some data is stored and how to manipulate that data. They expose the internal workings of the manufacturer’s product to the outsider. They tell the outsider where data is found and how to interpret it.
Ideally, a plug-in should be secure by virtue of its own design, adding it to an existing application would not add a new weakness, and the plug-in would not conflict with any other plug-ins used in the same application.
However, it seems that plug-ins sometimes conflict with each other. The first thing you are told if there is an issue with an application is to disable all plugins. And if you do a Google search, you will find companies selling plug-in conflict detection tools, so the problem is a genuine hazard.
Unfortunately, plugins, like any other computer program, may also contain errors that need to be corrected. So, the solution is to update. But of course, everyone has to implement the update, and we know just how difficult that is to achieve.
And finally, it can be strange to consider that IT departments install plugins without any knowledge of what impact they may have. A plug-in, for example, obtains the rights of the application it is plugged into, which may be very considerable indeed.
Plug-ins are clearly not a guarantee of security, and, if used at all, should be used with great care and caution. It seems that, “One man’s meat is another man’s poison”.
Plug-ins could be made secure, in the sense that by cryptography (digital signatures) the manufacturer can verify that plug-ins have been digitally signed before allowing the plug-in code to run (provided that the manufacturer evaluates and certifies all plug-in code before signing it so that every user may be certain that there can be no compromise to the application).
But only the manufacturer can do that – nobody else. And anyway, what would that mean? Are we to assume that the manufacturer has the technical ability to certify the security and quality of every plug-in that is digitally signed? Who is going to pay for that? It would create an immensely complex administration system, not to mention always having to have the manufacturer’s product being fully up to date.
Of course, this puts an enormous responsibility on the manufacturer to exercise high levels of due diligence if that strong control is to be exercised. If that strong control is not exercised, then in reality the providers of plug-ins have a free-for-all. Since they cannot know if they are the only plug-in running, and the nature and intent of any other plug-ins running at the same time as them, they cannot police the situation for themselves. In fact, just as they may expose the manufacturer’s system, they may also expose each other’s actions.
So let us say that a security plug-in is installed in a system. How will it protect itself against other plug-ins, or the manufacturer? What will be its approach to verifying the environment it finds itself in? Some security vendors providing plug-ins to inter-operate with other products have been unlucky, such as the PGP Outlook plug-in vulnerability reported at The Register where a security plug in weakness could compromize the system.
Clearly, placing blind trust in the manufacturer and all of their plug-in providers is a non-starter is folly. Security plugins are built on a foundation of sand. Any “security” they provide could collapse at any moment.
Why Locklizard for PDF DRM Protection?
Locklizard takes your document protection seriously. We provide total PDF protection with US Gov strength AES encryption, public key technology, DRM, and license controls, to ensure your PDF files remain protected regardless of their location.