Software vendor Adobe Systems Inc. recently released "Reader X," a new release of the Adobe Reader software commonly used to view PDF documents. This new version of Reader X is designed to reduce the effects of Adobe security flaws, which could be exploited via malicious PDF documents. As a security consultant, you need to ensure this new release is installed on all of your customers' Windows workstations.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The PDF format has been used to compromise computers via the transmission of malicious documents that exploit vulnerabilities within the viewing software. Malicious documents could be sent by email or could be placed on a compromised website, targeting the users of that site. For example, there have recently been many reports of malicious Adobe Flash content within a PDF that was used to install malware. Since the number of bugs, and thus the number of presumed security vulnerabilities, increases with the number of features and the size of the code, it is reasonable to presume that newer versions of the PDF rendering software, such as Acrobat and Reader, will also contain vulnerabilities that can be exploited by attackers.
The principles of defense-in-depth teach us to have additional compensating controls in place. To that end, this move by Adobe is quite welcome.
Reader X, however, offers a major new security feature: sandboxing (which Adobe formally calls Protected Mode). Also used in Google Inc.'s Chrome browser, sandboxing is a way of protecting users from malicious Web content. Let's review how sandboxing works.
Sandboxing isolates various functions within trusted and non-trusted components of Reader X, where the trusted component regulates what actions the untrusted component(s) can perform. Consider recent scenarios in which opening a PDF document caused the PDF to make a Web request, download a file and execute that file. Sandboxing prevents the security ramifications that can result from the execution of a malicious file by assuming that the exploit will happen and designing the software to limit the damage the exploit can do by putting the highest risk components in the sandbox and regulating that sandbox through the trusted component.
When describing this Adobe security feature, Adobe's security blog stated:
"This first release will sandbox all "write" calls. .... This will mitigate the risk of exploits seeking to install malware on the user's computer or otherwise change the computer's file system or registry. In future releases of Adobe Reader, we plan to extend the sandbox to include read-only activities to protect against attackers seeking to read sensitive information on the user's computer."
>The design of secure software typically includes an effort called threat modeling to identify the types of attacks that are likely to happen. By listing the attack vectors and consequences, usually using historical attack data, the developers can increase the resiliency of the software to those attacks. Adobe states its threat model for the development of Reader X included the following two attacks:
- Installing malware on the user's machine
- Monitoring the user's keystrokes when the user interacts with another program
Now that we've described what sandboxing (called "Protected Mode" by Adobe) is, let's describe what it's not: a cure-all to PDF security exploits. Although sandboxing is a great Adobe security feature and this release appears to offer a substantial security improvement over past versions of Reader, it is still quite possible that attackers will find a way to circumvent the sandboxing and gain the access they desire.
In fact, from a technical standpoint, the current Adobe Reader X sandboxing implementation is somewhat limited, meaning non-sandboxed features would be an easier target. Adobe lists the following threats not currently mitigated by the sandboxing implementation:
- Unauthorized read access to the file system or registry
- Network access
- Reading and writing to the Clipboard
- Insecure operating system configuration
Google's Chrome browser also uses sandboxing to make viewing PDFs safer. Chrome isolates the rendering engine, the element that receives Web content and determines what should be displayed into a limited access sandbox. The rendering engine does not have direct access to many OS components, such as the file system. Each browser tab is a separate sandboxed rendering instance that reduces the ability for Web-borne malware to interact with other webpages. Despite this, browser plugins (such as Adobe Flash) run outside of the sandbox for the sake of compatibility, which minimizes the effective level of security offered by Chrome. Still, opening PDFs with Chrome's PDF viewer does provide some protection against malware. You should coach your customers to encourage their users to use Chrome or other protective measures whenever they view or download a PDF on the Internet.
Reader X, as with Chrome, is moving to an architecture designed explicitly with improved Adobe security in mind, based on lessons learned from previous attacks. Software should never be assumed to be vulnerability free, and the principles of defense-in-depth teach us to have additional compensating controls in place to protect customers from vulnerabilities in the software they use. To that end, this move by Adobe is quite welcome.
Be aware, however, that Reader X is a new product version of Adobe Reader, not simply an update. This means that the automatic update feature, if that is even being used by your customers, will not install Reader X without special intervention. A separate software installation will be needed to install this version of the software. As their trusted security consultant, you will need to proactively take steps to install Reader X on your customer's desktop and laptop computers, or at a minimum make sure they understand the importance of installing Reader X themselves and the risks of not doing so promptly.
About the author:
Tom Chmielarski is a Senior Consultant at GlassHouse Technologies.