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
At first sight, plugins (software components that add features to existing applications – most typically browsers) offer a superior way of delivering Digital Rights Management (DRM) functionality into PDF documents on an end user device (desktop, laptop, tablet and so on).
The attractions are that plugins may be delivered ‘seamlessly’ through the browser, that they inherit all the authority of the browser, and act transparently so the end user need not be aware that they are there. Users would be amazed to find out just how many plugins (or add-ons) are already installed in their browsers and they never noticed. Good bets you will find Flash, Quicktime, Java, WordPress, Moodle, IrfanView and so on.
So a well-designed plugin can offer good PDF security because it can be delivered reasonably easily, has direct access into the browser functionality and a connection to the Internet already provided so it can download documents as required and do any user authentication required.
However, in practice there are some problems when it comes to the implementation.
Current security controls often require an Administrator to allow them to be installed, just the same as an executable does, so that makes them the same as installing application software. However, unlike application software they can create a gateway for other applications or malware to enter, decreasing the overall security of the application they are plugged in to.
Browsers can run many plugins at the same time, and the plugins are not ‘aware’ of each other, and therefore of any conflict over the resources they are using. So it is possible for them to be in conflict with each other when using the same data (they are using the browser’s data so there is no sand box control) and it can be a complex thing for the plugin supplier to test out their plugin with all the commonest suppliers to make sure everything works. There is no formal testing process by the browser providers.
By studying a plugin it is possible to see where it acts on data and design another plugin to take advantage by grabbing the data being processed. It is also possible to manipulate plugins to allow malware to be uploaded into a user machine.
Browsers are always in a state of update. And there is no coordinated schedule of when they are changing or what is changing. So you can certainly participate in the browser beta schedules – the manufacturers helpfully make their expected release candidates available to extend their own testing capabilities – but changes to other plugins cannot be easily coped with. So, if Adobe change their links for handling PDF files in Acrobat, separate plugins to process the PDF files may be affected and stop working.
This is compounded by the presence of different versions of browsers on different platforms. So when updates roll through things can stop working for a while. And some corporations only allow versions of the browser that they have locked down, and this may not be compatible with updated plugins either. So whilst the automatic plugins of the big software suppliers for PDF, Flash and Quicktime mainly work OK for corporates other plugins have no guarantee.
There are also a lot of differences between the corporate world and the consumer. Corporates move slowly, preferring to be behind the curve on the systems they are running – not on the bleeding edge. Consumers often look for the latest and greatest and frequently change their environments. This diversity gives the plugin provider serious operational problems.
Increasingly plugins are a part of life. You only have to look at WordPress to see how extensively plugins are required for normal processing, but they may not be too useful where security is required, as in PDF DRM. Here you have to rely on the PDF security plugin working as expected (not conflicting or being circumvented by other plugins) and not failing to operate when Acrobat is frequently updated. If you cannot achieve that then the plugin is effectively useless.
To read more about Adobe Security Plugins see:
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 – Adobe Plug-ins compromised – the plug-in with forged signature can perform virtually everything, including but not limited to:
The official US-CERT posting can be viewed here along with Adobe’s response.
Why Locklizard for PDF Protection?
Locklizard document security cannot be compromised by plugins because we prevent all plug-ins from loading so that no vulnerabilities can be introduced.
Locklizard takes your document protection seriously. We provide total PDF protection with US Gov strength AES encryption, public key technology, DRM and licensing controls, to ensure your PDF files remain protected no matter where they reside.