Plugins can be overruled
A plugin from one manufacturer can stop a plugin from another manufacturer from:
- not working correctly
- not working at all
- changing what controls it enforces
Adobe PDF Security Plugins & Plug-in Vulnerabilities
Free 15 Day Trial
Trusted by:
 |
PDF Plug-in Vulnerabilities & Acrobat Reader Security |
Plug-ins are dangerous. If you rely on plug-ins for your PDF security then you should be aware that they may not have all the security that 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 convienient, they require Admin rights to install and can put your protected PDF documents at risk.
 |
Adobe Plug-ins and PDF Plugin Security issues |
Adobe PDF plugins
In the PDF world it is commonplace to use plug-ins 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:
http://www.kb.cert.org/vuls/id/JSHA-5PAMS7
However, it is openly admitted that ‘legitimate’ plug-ins may compromize the security of a system. We reproduce some of the text published in the CERT report:
“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 plug-ins. The Certified Mode of both Adobe Acrobat and Adobe Reader is used to provide added assurances that only plug-ins provided by Adobe are compatible. All third party plug-ins are restricted to non-certified mode.”
And
“Be careful not to install untrusted software, including non-certified Adobe plug-ins (those not signed and deployed by Adobe), unless absolutely certain of the origin and integrity of such software. Unverified non-certified plug-ins can be removed from the plug-ins directory, and they will no longer load at startup.”
So what does this all mean?
- A company may have an IKLA with Adobe Systems, but that does not mean that their product is certified as fit for purpose and is not vulnerable to weaknesses in the system or does not create weaknesses in the system.
- If you examine the licensing system in force at the date if this article, anyone can write a plug-in for Adobe Acrobat Standard or Professional without obtaining an IKLA. That means any third party can write a perfectly valid and appropriate plug-in that extracts text from an open PDF document without it having been deliberately designed to break any security systems. Unfortunately, by it’s very nature it does just that. There are many legitimate plug-ins on the market today that have this capability which are not hacking tools and were not developed for that purpose.
We respect the advice given by CERT, but note that if an attacker permits the loading of unverified non-certified plug-ins (which happens by default in all versions of Adobe 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 therefore do.
Normal users familiar with their desktop plug-ins can hardly be criticized for using non-certified plug-ins when you can hardly expect them to understand any of these arcane technical issues, still less comply with them.
Adobe PDF plugins and certified mode “protection”
There are many Adobe Acrobat and Adobe Reader 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 plug-ins, loaded with those ones, have been also certified by Adobe. However, with this vulnerability, a plug-in with forged signature can perform virtually everything, including but not limited to:
- removing or modifying any restrictions (from copying text to Clipboard, printing etc) from the documents loaded into Adobe Acrobat or Adobe Reader
- remove any DRM (Digital Rights Management) schemes from PDF documents, regardless the encryption handler used – WebBuy, InterTrust DocBox, Adobe DRM (EBX) etc.
- modify or remove digital signatures used within a PDF document
- affect any/all other aspects of a document’s confidentiality, integrity and authenticity.
Still think plug-ins are safe?
Don’t just take our word for it, if you think plug-ins can’t compromise your security then read what Byran Guignard, an Adobe Certified expert, has to say.
The following white paper, Plug-ins – a source of insecurity, examines and questions the claims often made by plug-in 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.
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.
And if you are forced to turn off security in Adobe Acrobat in order 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 APIs and plug-ins can compromize security |
Why use plugins and what do they do?
Many software product manufacturers provide customer access into their products. There are many reasons to do this, including:
- allow for local customization
- allow extra facilities to be added
- support features not provided by the manufacturer
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 available information 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.
Are plugins secure, and what do we mean by secure?
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, plug-ins, like any other computer programs, 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.
So plug-ins are 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”.
Can plugins be made secure?
Plug-ins and APIs 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 and 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 as to what they actually do. And 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 have no ability to 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 or API is installed in a system. How will it protect itself against other plug-ins, or against the manufacturer? What will be its approach to verifying the environment it finds itself in? Some security vendors providing plug-ins to interoperate 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.
Of course you can always just place blind trust in the manufacturer and all the plug-in providers. I guess that’s how we got into the virus, worm, spam and intruder mess. We just put blind trust in the providers of computer systems that there were no threats and risks and we did not need any controls.
Self-evidently we were wrong on that occasion. Major industries have since made fortunes out of the fact that we did not have any security, and now we have to rely heavily on their products to keep us safe. But the important conclusion we have to draw is that putting trust in the manufacturer to get it right and control the system perfectly every time isn’t working.
It seems clear, as the spam wars develop, that manufacturers are changing from providing technical quality to threatening transgressors with litigation instead. The digital millennium copyright act (DMCA) is an excellent example of where industry forbids any examination of a claimed security mechanism and tries to make any research (never mind actual compromise) a criminal activity. As a result manufacturers are encouraged to make outrageous claims about their security safe in the knowledge that any attempt at criticism will be met with a criminal prosecution instead of a high quality system.
 |
Why Locklizard for PDF Protection? |
Locklizard PDF Security – Total PDF DRM Security without Plugins or Passwords
Locklizard takes your document protection seriously. We provide total PDF protection with US Gov strength AES 256 bit encryption, public key technology, DRM and licensing controls, to ensure your PDF files remain protected no matter where they reside.
- Our DRM PDF Security products enable you to share documents securely without insecure passwords or plug-ins, and enforce access, location, expiry, and usage controls.
- Locklizard DRM security cannot be compromised by plug-ins because we prevent all plug-ins from being loaded so that no vulnerabilities can be introduced.
- Unlike Adobe Permissions which can be easily removed, our DRM controls persistently protect your PDF files and enable you to revoke PDFs at any time regardless of where they are.
- No keys are exposed to users or interfaces and documents are only ever decrypted in memory – see our DRM technology.
- No uploading of unprotected documents to the cloud where they could be easily compromised.
- Our easy to use adminsitration system provides simple user and document management and unlike passwords, keys are transparently and securely managed for you.
See our customer testimonials or read our case studies to see why thousands of organizations use Locklizard PDF security to securely share and sell their documents.
Customer Testimonials
