Adobe’s Portable Document Format (PDF) is the single most popular file format for sharing documents on the Internet. Supported by a free viewer (Adobe Reader) on all major computing platforms, it allows people to read faithfully rendered documents created in hundreds of programs (either natively or converted to PDF using Adobe Acrobat). But it’s very popularity and ubiquity is a challenge to security; allowing attackers to target a single program widely used on Macs, Windows PCs, and Linux systems. And the very flexibility that allows a PDF file to include everything from a complex presentation, to a government form, to a high-end catalog, creates a wide attack surface for criminals to take advantage of.
Exploited against Windows, that is.
Now the good news: None of these real-world attacks targeted Macs; and while Mac users are just as vulnerable to these flaws, practically speaking, the bad guys still focus on Windows. Better still, major security changes that Adobe announced in 2009 are finally coming to fruition and resulting in more secure products with the release of Acrobat X and Reader X (although the biggest change is limited to Windows).
Security and PDFs
Although most of us think of PDF files merely as an easy way to share text documents and forms, the PDF format is actually a very complex structure capable of supporting all sorts of embedded content and logic. Faithfully rendering consistent fonts and colors across a wide range of totally divergent platforms (including printing) is a difficult challenge exacerbated when you add audio, video, Flash, JavaScript, forms, and more. Not all PDF creation or viewing tools support all this advanced functionality, but as the creator of the standard, Adobe supports the widest range of content in Acrobat and Reader. This leads to two big opportunities for security problems.
Adobe Reader and Acrobat support JavaScript and Flash within PDFs. These full programming languages create opportunities for attackers to build malicious PDFs that execute when you open the file. Adobe does limit what sorts of actions are supported in PDFs, but attackers have found ways to break through these to reach your computer; just as they often do with your Web browser (another tool that supports JavaScript and many content types).
The next problem is Reader’s extensive support for embedded content. To display each of those content elements, Reader requires a parser—a bit of software to interpret the content and display it properly, each of which is a potential point of failure. Attacks usually exploit these flaws by creating malformed content in a PDF that crashes the parser and executes a memory corruption attack like a buffer overflow. As Reader goes to display the embedded content it calls the parser, which tries to read the bad file and crashes, thus corrupting memory and potentially allowing the attacker to execute their own code embedded in the PDF and take over your computer (this is the most common attack used by malware).
There are very few kinds of programs that display as many different kinds of content as Reader. And what makes Reader particularly concerning is that it shares much of its code base across different platforms, which means the same vulnerability might be exploitable on both a Mac and a PC.
While these are real vulnerabilities, frequently exploited on Windows, so far it’s almost unheard of to see them exploited on Macs. I can’t find a single case of a cross-platform vulnerability exploited in the real world across both platforms. While exploiting many of these vulnerabilities isn’t inherently more difficult on a Mac (I’ve seen demonstrations by researchers), practically speaking it’s not as easy a target. There are fewer Macs in the world, and due to OS X’s built-in PDF support, even fewer Mac users install Reader.
Creating a cross platform exploit is even more difficult since you need to embed code to figure out what kind of platform it’s on, and then run the proper attack. In practice, this often isn’t possible.
Security in Acrobat and Reader X
The biggest security improvements in Reader X are in the Windows version, since that’s where Adobe sees most attacks, but Mac users, and Windows users of Acrobat X, aren’t left completely out.
Across both platforms Adobe implemented an intensive code hardening program designed to reduce vulnerabilities. This security development process includes a combination of testing, code review, and programming standards, all focused on reducing security flaws. Adobe started the program years ago for new code, and for Reader and Acrobat X the company went back and reviewed critical parts of older code that makes up most of the products.
Adobe recognized that users don’t always understand security alerts or preference settings and improved their usability. For settings, items are better labeled, while for alerts, Adobe moved away from Yes/No dialog boxes that users instinctively click without reading. Instead, Reader drops down a yellow alert bar with descriptive text for the user to then click and choose an option, just like some Web browsers do.
Adobe also improved the JavaScript blacklist framework, which allows you to disable all JavaScript, or only specific functions. Previously, you were only able to completely disable JavaScript, which could adversely affect even simple documents. Few home users will ever touch this feature, but in corporate environments this allows administrators to ban a vulnerable JavaScript function without bringing down the entire business.
Next, Adobe improved the updater for both Mac and Windows. On Macs, the updater finally uses a standard Apple installer, checks for updates, and downloads them every 72 hours to install next time you run the software.
On Macs, Adobe uses the built-in security features of OS X to reduce the risk of memory corruption attacks. Also, the Reader plugin for Safari is now 64-bit, which carries additional security benefits (the stand-alone Reader is still 32-bit).
Seeing the security future in Windows
The single biggest security change in Reader X is the addition of sandboxing, but it’s only available for Windows. Sandboxing is a powerful security tool that isolates what an attacker can do even if they successfully exploit Reader.
Sandboxing uses features of the operating system to isolate parts of a program, such as the PDF image parser. It runs these processes in a restricted mode compared to the rest of the software, limiting how they interact with the computer. For example, the sandbox can restrict the ability of anything running inside it from saving files on the local hard drive. Even if an attacker exploits the vulnerable parser, if the controls work properly, they can’t install persistent malware on the system. And, ideally, even if their malicious code runs in memory, it’s restricted to the compromised part of the software and can’t access the rest of the machine.
Thus, to compromise a system, the attacker needs to exploit a vulnerable process in the sandbox, then break out of the sandbox into the rest of Reader, then break out of Reader into Windows, and then gain control over Windows.
So why didn’t Adobe include sandboxing on Macs? It isn’t from a lack of support—OS X does include sandboxing features for developers. According to Brad Arkin, Adobe’s director of product security and privacy, there simply aren’t enough attacks against Macs to justify the development effort. It’s hard to argue with this logic, especially since we have never seen a single piece of malware targeting Adobe Reader or Acrobat on the Mac.
Despite all the vulnerabilities, and the mass exploitation of Reader and Acrobat on Windows, the actual risk to a Mac user today is immeasurably low. We just aren’t seeing the attacks. But since there is no technical obstacle to exploiting a Mac running a vulnerable version of Acrobat or Reader, I still suggest keeping your eyes open for that dreaded day when some outlaw finally gets bored with the Windows platform.
[Rich Mogull has worked in the security world for 17 years. He writes for TidBits and works as a security analyst through Securosis.com.]