The Adobe Reader Sandbox

One of the most attacked programs on users’ PCs is Adobe’s Reader, a PDF viewer. It has mighty features like JavaScript support – which aren’t used too often by most people – which increase the complexity of the software and thus the attack surface. As Adobe tries to increase the security of the software, it introduces things like a Patchday cycle like Microsoft has; and the newest addition is the so-called sandbox in Adobe Reader.

A sandbox works like the name suggests: every change and action is done within a controlled, separated environment. Basically, the idea is to restrict the actions a (malicious) document can do on a system, like writing in certain places, reading from the registry, connecting to Internet, and so on. In theory, an exploit taking place will then hijack the Reader process, but that process is limited in its system rights and cannot do any harm. The concept of Adobe’s sandbox is similar to that of Microsoft Office 2007 MOICE, Google Chrome, and Office 2010 Protected View.

This approach is very good, it is “security in depth” which actually means to have many and also overlapping security walls in the system.

Adobe’s Reader uses Windows operating system features to mitigate certain classes of attacks and to help defend against attempts made by a malicious PDF file seeking to exploit a vulnerability in the product. This is a good thing for the users. Until now, they need to update their Adobe products very often unless they want to be pray for some Adobe 0-day exploit.

The principle behind any sandbox is quite simple to describe, but very complex to implement. Basically, the process which is being sandboxed has to work according to the principle of the least privilege, meaning that it can’t do too many things by its own. The process transparently calls some APIs which aren’t actually the APIs of the underlying OS but those are provided and filtered by the sandbox. The sandbox can allow or deny the usage of potentially dangerous APIs, or simply deny any write or execute actions coming from the sandboxed process.

For implementing the sandbox, it is necessary to decouple the business logic (viewing the result) from implementation logic (doing the file access and computation and rendering itself). To apply the principle of least privilege, the operating system dependent operations like file input-/output operations have to be done in a separated process which offers its services to the business logic.

Like any other software feature, this security feature is just as reliable as its implementation is and, in this particular case, also just as reliable as the underlying operating system is. The experience from the last years showed us that despite the fact that both companies, Microsoft and Adobe, have done major steps in enhancing the products security, their products are always in the top of the most vulnerable software.

If Adobe manages to implement this feature right, this would be a relief on their users. Even if there would be a new 0-day exploit in the software, the users will be protected because the PDF renderer can’t use the operating system’s functions to do any harm.

For an even better protection, the users can follow some simple steps:

  • Work in a non-privileged account
  • Keep the software up to date
  • Use an anti-malware software and keep it up to date
  • Make sure to enable Enhanced Security in Adobe Reader (default activated in versions higher than 8.2 and 9.3) as this is the sandbox
  • Deactivate the JavaScript functionality in Adobe Reader
  • Just open PDF documents from trustworthy sources

The main problem with Adobe Reader is outdated versions though. Most users don’t care about that – and they should not need to; software should update automatically and silent in the background. Even Adobe is working on such an update mechanism which Google uses very successfully with their Chrome web browser. But this doesn’t help our Dads, Uncles and Grandmothers which have installed version 6 from a few years ago, when the computer was bought.

Sorin Mustaca
Data Security Expert

Dirk Knop
Technical Editor