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
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
News
FluBot Malware's Rapid Spread May Soon Hit US Phones
Kelly Sheridan, Staff Editor, Dark Reading,  4/28/2021
Slideshows
7 Modern-Day Cybersecurity Realities
Steve Zurier, Contributing Writer,  4/30/2021
Commentary
How to Secure Employees' Home Wi-Fi Networks
Bert Kashyap, CEO and Co-Founder at SecureW2,  4/28/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-22675
PUBLISHED: 2021-05-07
The affected product is vulnerable to integer overflow while parsing malformed over-the-air firmware update files, which may allow an attacker to remotely execute code on SimpleLink Wi-Fi (MSP432E4 SDK: v4.20.00.12 and prior, CC32XX SDK v4.30.00.06 and prior, CC13X0 SDK versions prior to v4.10.03, C...
CVE-2021-22679
PUBLISHED: 2021-05-07
The affected product is vulnerable to an integer overflow while processing HTTP headers, which may allow an attacker to remotely execute code on the SimpleLink Wi-Fi (MSP432E4 SDK: v4.20.00.12 and prior, CC32XX SDK v4.30.00.06 and prior, CC13X0 SDK versions prior to v4.10.03, CC13X2 and CC26XX SDK v...
CVE-2020-14009
PUBLISHED: 2021-05-07
Proofpoint Enterprise Protection (PPS/PoD) before 8.17.0 contains a vulnerability that could allow an attacker to deliver an email message with a malicious attachment that bypasses scanning and file-blocking rules. The vulnerability exists because messages with certain crafted and malformed multipar...
CVE-2021-21984
PUBLISHED: 2021-05-07
VMware vRealize Business for Cloud 7.x prior to 7.6.0 contains a remote code execution vulnerability due to an unauthorised end point. A malicious actor with network access may exploit this issue causing unauthorised remote code execution on vRealize Business for Cloud Virtual Appliance.
CVE-2021-26122
PUBLISHED: 2021-05-07
LivingLogic XIST4C before 0.107.8 allows XSS via feedback.htm or feedback.wihtm.