20
Jul 10

Adobe: ‘Sandbox’ Will Stave Off Reader Attacks

facebooktwittergoogle_plusredditpinterestlinkedinmail

Adobe Systems Inc. said today the next release of its free PDF Reader application will include new “sandbox” technology aimed at blocking the exploitation of previously unidentified security holes in its software.

Sandboxing is an established security mechanism that runs the targeted application in a confined environment that blocks specific actions by that app, such as installing or deleting files, or modifying system information. Adobe said that in developing the sandbox technology, it relied on experts from Microsoft and Google (the latter already has incorporated sandboxing into its Chrome Web browser).

“The idea is to run Reader in a lower-privilege mode so that even if an attacker finds an exploit or vulnerability in Reader, it runs in lower rights mode, which should block the installation of [malware], deleting things on the system, or tampering with the [Windows] registry,” said Brad Arkin, director of product security and privacy at Adobe.

Even if only somewhat effective, the new protections would be a major advancement for one of the computing world’s most ubiquitous and oft-targeted software applications. The company is constantly shipping updates to block new attacks: Less than a month ago, Adobe rushed out a patch to plug vulnerabilities that hackers were using to break into vulnerable machines. Security vendor McAfee found that roughly 28 percent of all known software exploits in the first quarter of 2010 targeted Adobe Reader vulnerabilities. According to anti-virus maker F-Secure, Reader is now the most-exploited application for Windows.

Reader still has to legitimately touch the underlying filesystem in order to save PDF files, but it will be configured to work through a separate Adobe “broker process,” such that any attempts by Reader to communicate directly with the operating system will fail, Arkin said.

“Under such a system, not only would the attacker have to find a vulnerability in Reader, but they’d also have to carry out a second-stage attack from the Reader process to the broker process,” he said. “We have put in a place a very small set of policies to make sure that any action the broker process takes on behalf of Reader is absolutely necessary for operation.”

The initial release will not sandbox “read-only” activities in Reader, such as accessing content on the user’s system, but that functionality may be incorporated into versions down the road.

Arkin said the new feature will be on by default, and will not affect the performance or speed of the application.

“The vast majority of users will never know it’s there,” Arkin said. “It doesn’t increase the number of dialogue boxes or choices, and users should be able to continue to interact with Reader the same way they always have.”

Didier Stevens, a Belgian security researcher who has discovered and reported a number of security vulnerabilities in Reader, said Adobe’s planned protections should indeed block most known PDF-based malware.

“When I read ‘sandboxing of all write calls’ I said to myself: ‘That’s easy to bypass, for example by injecting code into another process (e.g. Windows Explorer) and let it write to disk’,” Stevens wrote in an e-mail to KrebsOnSecurity.com. “But then I read that registry and process calls are also sandboxed, so injecting code inside another process would be blocked.”

Stevens said the broker process could end up being the weakest link of Adobe’s sandbox approach.

“If you can mislead the broker process, you can still get access,” Stevens said. “If similar bugs exist in the broker process, then researchers will soon find them. And I hope this mechanism fails gracefully: if the broker process breaks down, then every action should be denied.”

Adobe isn’t willing to set a date certain for the release of the new sandboxed Reader, but said it should ship in the next version, due out before the end of the year. Arkin said the sandboxing feature will initially be available only for the Windows version of Reader.

“Our primary goal was to protect the largest number of users the fastest,” Arkin said. “In the lab it’s certainly possible to take one of those [vulnerabilities] and export it onto a different platform, but in the real world, every single attack we’ve heard about has been on a Windows platform.”

Tags: , , , , , ,

15 comments

  1. I have switched to non-Adobe products wherever possible for a number of reasons. This step (while apparently well-intentioned) appears at this point to be mainly corporate damage control. We’ll just have to wait and see the results.

    • Damn! Seems a lot of work to protect the pig when all you need to do is fix the pig. I love the phrase ‘ previously unidentified security holes’. Have they never thought of a thorough security audit a la Theo de Raadt?

  2. Adobe’s “sandboxing” initiative is all well and fine, but what’s really needed is a re-architecture of PDF into a “Secure Document Format”, with all of the JavaScript, file attachment, multimedia and any other capabilities other than the absolute minimum subset of PostScript needed to render a document removed.

  3. Very good news, and about time; some of my clients can’t switch to Foxit Reader.

  4. Maybe Adobe would be kind enough to deal with some of their ‘bloat’ at the same time as making their product more secure.
    IMO Foxit is the way to go if you only read – rather than write – PDFs.

  5. Hey Adobe, instead of adding more code (potentially more crappy code) why not just create a Reader Lite for the 80% of us that don’t want or use the Adobe Reader advanced features… if we do.. we can use the full feature Reader…

    That would get me using your product again… but not this…

    • Just taking all the bells and whistles out of the spec would do a lot to making the client code thinner. And this in turn would make it easier to consolidate the remaining code and hopefully weed out any remaining bugs.

  6. BattleChicken

    I always thought it was strange that a document *reader* required write access at all.

  7. If you want to run Adobe Reader and/or any other applications, such as your web browser and e-mail client, in a traditional, actual sandbox, then visit http://www.sandboxie.com and download Ronen Tzur’s Sandboxie utility. It is free of charge with some functionality added if you pay the one-time license fee, but it is not crippleware. Be forewarned, though that it does require some time and effort to configure the sandbox(es) which you choose to use. The configuration is effected by using a component of the primary program, or by editing the configuration file directly (which has a learning curve). Sandboxie is well documented, although sometimes it does not immediately cover all of the new aspects of using it in the most recent version. The user forum is a friendly place to receive expert advice and aid, often from “tzuk” himself. I’ve been using it since November 2008, and run Firefox, Thunderbird, I.E. 8, and iPodder in sandboxes, not in straightjackets.

  8. Thank goodness no one on OS X has needed that reader for a long time. With all happening on OS X, one app keeps going forward: Preview. +5 for that one!

  9. Getting rid of Javascript in a freakin’ document reader will “stave off Reader attacks” MUCH more reliably than any patch.


Read previous post:
Skimmers Siphoning Card Data at the Pump

Thieves recently attached bank card skimmers to gas pumps at more than 30 service stations along several major highways in...

Close