Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

10/20/2010
04:48 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

What Adobe's New PDF Sandbox Really Means For Attackers

Adobe Reader X's 'Protected Mode' will make PDF attacks tougher to execute, but it can't stop every threat

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.

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Hacking It as a CISO: Advice for Security Leadership
Kelly Sheridan, Staff Editor, Dark Reading,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8720
PUBLISHED: 2020-08-13
Buffer overflow in a subsystem for some Intel(R) Server Boards, Server Systems and Compute Modules before version 1.59 may allow a privileged user to potentially enable denial of service via local access.
CVE-2020-12300
PUBLISHED: 2020-08-13
Uninitialized pointer in BIOS firmware for Intel(R) Server Board Families S2600CW, S2600KP, S2600TP, and S2600WT may allow a privileged user to potentially enable escalation of privilege via local access.
CVE-2020-12301
PUBLISHED: 2020-08-13
Improper initialization in BIOS firmware for Intel(R) Server Board Families S2600ST, S2600BP and S2600WF may allow a privileged user to potentially enable escalation of privilege via local access.
CVE-2020-7307
PUBLISHED: 2020-08-13
Unprotected Storage of Credentials vulnerability in McAfee Data Loss Prevention (DLP) for Mac prior to 11.5.2 allows local users to gain access to the RiskDB username and password via unprotected log files containing plain text credentials.
CVE-2020-8679
PUBLISHED: 2020-08-13
Out-of-bounds write in Kernel Mode Driver for some Intel(R) Graphics Drivers before version 26.20.100.7755 may allow an authenticated user to potentially enable denial of service via local access.