What Adobe's New PDF Sandbox Really Means For Attackers

It has been a busy year for Adobe security, issuing multiple patches for zero-day flaws and attacks aimed at its software as attacks on its pervasive Reader application have exploded. Now comes the official announcement of its expected Protected Mode sandboxing feature in the new Adobe Reader Version X.

Sandboxing basically quarantines any operations to a confined, restricted space so that if a PDF were infected with malware, the malicious code couldn't spread outside that file and into the system itself or to other files. The new feature is part of Adobe's security strategy of hardening its code against attacks, says Brad Arkin, senior director of product security and privacy for Adobe.

Poisoned PDFs are one of the most popular vehicles for carrying malicious code, and security experts applauded Adobe for the new Protected Mode feature. Adobe has been systematically beefing up its security posture during the past year, starting with its automatic updater feature for Reader and Acrobat and a regular patching schedule. The company first announced the sandboxing approach this summer.

"This is an approach I agree with," says security researcher Dino Dai Zovi, of the new sandboxing feature, which will be available next month. "It will provide them more protection and faster than being able to release patches for all of the vulnerabilities they will find."

But just how much can the new Reader sandbox in Adobe Reader X deter attackers?

Adobe's Protected Mode is aimed at stopping attackers from installing malware, recruiting bots, and conducting any malicious activity on a Reader user's machine, Adobe's Arkin says. "The initial implementation of sandboxing is going to restrict the ability of Reader to process on a Windows machine and perform any write calls to the OS -- creating, changing, or deleting a filesystem file, kicking off new process, starting a new app, or tampering with a registry," he says.

An upcoming version of the feature will stop "read" calls from a PDF as well, so an attacker can't read or access file systems, he says.

"We're hoping that [PDF] attacks will [now] be more difficult to carry out and will be less reliable," Arkin says. "Our goal [with sandboxing] was to defend against all potential vulnerabilities that may still be latent in the code and that we haven't found and fixed yet. We want to make attacks the bad guys are trying to do more expensive."

Reader's sandbox does not, however, protect against phishing or social engineering-based lures. "The sandbox does nothing against attacks where you have text inside a PDF that tells you to visit this URL and you submit your credentials [there]," Arkin says.

It can't protect a user from a malicious link embedded in a sandboxed PDF, either. "When you click on it, depending on how you have your settings, you will get a dialog box that asks if you want to open [the link]," Arkin says. If you do, he says, you might be attacked with malicious code.

Nor can it save you from a poorly configured password for your PDF. "A sandbox has nothing to do with the security of the file itself if the wrong person is able to open it," he says. "And if you're using keys to do signatures or other cryptographic operations on PDFs, maybe you need to protect how you store those keys."

And like any software, a sandbox can be broken, says security expert Lucas Lundgren. "We all have to remember that the sandbox solution is software-based, and software can be broken. Just like [Microsoft's] DEP and ASLR, for instance: They sounded good, but in the end could be bypassed."

Lundgren sees the sandbox as an "emergency," short-term solution. "What they need to do is redesign PDF and Reader, tidy up the bloat, and then implement a sandbox solution," he says.

Adobe has battle-tested the sandbox and had outside white-hat hackers pound away at it as well. The overall design has proved to be sound, Adobe's Arkin says. For an attacker to break out of the sandbox, he would have to find a flaw in it that has not yet been discovered, he says. "There's nothing we're aware of that the bad guy can use. It doesn't mean it's perfect," he says. "There's going to be so much research and work put into it that it may be possible to find flaws [eventually]."

Researcher Dai Zovi predicts that researchers will show off some attacks on the sandbox at Black Hat this year, but no exploits will be out in the wild before that. He says it's unclear whether attackers might use a Windows kernel exploit or an evasion method specific to Adobe to get their attacks through. "It depends on the quality of their [Adobe's] sandbox and how difficult it is to evade," he says. "Attackers are research-constrained as well. They will go for the easiest way to target you."

With the Reader sandbox making it tougher for bad guys to send their payloads via a PDF, they could move to Java plug-ins or other increasingly popular targets, experts say.

Or modules within Reader could be used as another vehicle for malicious code, Dai Zovi says.

Meanwhile, Adobe already uses some sandboxing features in its Flash application and is currently working with Google Chrome's development team to integrate Flash into the browser. Chrome uses the same sandboxing method that Reader is adopting, as does Microsoft in its Office 2010. "We are working with Flash and Chrome [development teams] to extend that integration to include Flash in the Chrome sandbox," Arkin says.

"We're hoping the bad guys will go elsewhere," he says.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.