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
berryjohnson
50%
50%
berryjohnson,
User Rank: Apprentice
1/16/2020 | 2:35:02 AM
Some useful guide about PDF file
To protect a pdf file from attackers we must use the password protection method. Also, the password must be strong and have numeric, numbers, special characters because of the combination of all these characters is hard to unlock or hack. If you have already some pdf file and want to convert pdf to word document offline so you can use some ways via a mention in the linked article.
Stop Defending Everything
Kevin Kurzawa, Senior Information Security Auditor,  2/12/2020
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
Architectural Analysis IDs 78 Specific Risks in Machine-Learning Systems
Jai Vijayan, Contributing Writer,  2/13/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19325
PUBLISHED: 2020-02-17
SilverStripe through 4.4.x before 4.4.5 and 4.5.x before 4.5.2 allows Reflected XSS on the login form and custom forms. Silverstripe Forms allow malicious HTML or JavaScript to be inserted through non-scalar FormField attributes, which allows performing XSS (Cross-Site Scripting) on some forms built...
CVE-2020-1693
PUBLISHED: 2020-02-17
A flaw was found in Spacewalk up to version 2.9 where it was vulnerable to XML internal entity attacks via the /rpc/api endpoint. An unauthenticated remote attacker could use this flaw to retrieve the content of certain files and trigger a denial of service, or in certain circumstances, execute arbi...
CVE-2020-1828
PUBLISHED: 2020-02-17
Huawei NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00; and Secospace USG6600 and USG9500 versions V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, and V500R005C00 have an input validation vulnerability where the IPSec module does not validate a field in a specific message. ...
CVE-2020-1857
PUBLISHED: 2020-02-17
Huawei NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00SPC100; and Secospace USG6600 and USG9500 versions V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, and V500R005C00SPC100 have an information leakage vulnerability. Due to improper processing of some data, a local authent...
CVE-2020-1858
PUBLISHED: 2020-02-17
Huawei products NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00SPC100; Secospace USG6600 versions V500R001C30SPC600, V500R001C60SPC500, and V500R005C00SPC100; and USG9500 versions V500R001C30SPC600, V500R001C60SPC500, and V500R005C00SPC100 have a denial of service vulnerability. Att...