Problem solve Get help with specific problems with your technologies, process and projects.

How an Adobe Reader zero-day exploit escapes sandboxing capabilities

Expert Nick Lewis explains how a recent zero-day exploit escaped the Adobe Reader sandbox, and whether it's likely to happen again.

A recent Adobe Reader zero-day exploit is notable for being the first in the wild to fully escape Reader's sandboxing capabilities. Could you explain how this attack works? Does it cast doubt on sandboxing as an effective enterprise application hardening technique?

Ask the Expert!

SearchSecurity expert Nick Lewis is standing by to answer your questions about enterprise security threats. Submit your question via email. (All questions are anonymous.)

Zero days like February's Adobe exploit validate the necessity of a defense-in-depth approach to enterprise security. To recap, security vendor FireEye first discovered the Trojan.666 malware, which used a complex set of techniques to exploit two different bugs. This particular attack worked by using JavaScript embedded in the malicious PDF to put an exploit into memory and load several dynamic link libraries with malicious code to execute. The result was a successful bypass of the Address Space Layout Randomization and Data Execution Prevention technologies Adobe relies on for its "sandbox" or protected zone, which is supposed to keep applications and their files from ever having a malicious effect on their hosts.

A moat filled with sharknadoes is insufficient protection if it can be bypassed by a helicopter. There should be additional protections in place that will keep intruders out in case one defense fails. This is not to say there should be an infinite number of moats and flying sharks, but enterprises should evaluate the risk and the additional cost so the sharks with lasers aren't just protecting the public website.

Even if Adobe made perfectly secure software and a perfectly secure sandbox, the company cannot defend all areas of the device its software runs on from potential vulnerabilities. Adobe, to its credit, patched the sandbox-escape vulnerability quickly. Enterprises should disable JavaScript functionality on users' systems to whatever extent is possible, and administrators should configure Adobe products installed to automatically implement software security patches as soon as Adobe makes them available going forward. If Reader or any other software isn't needed, it should not be installed; unnecessary software is only broadening an organization's attack surface.

The intent of the Adobe Reader and Acrobat sandbox is to make it significantly more difficult for attackers to exploit the software. An attacker must spend considerably more time and money developing exploits for Reader and Acrobat than was necessary a year or two ago. Clearly there's no such thing as a perfect defensive technology, but sandboxing by and large has made a difference in making software safer, and will surely continue to do so despite this minor setback.

This was last published in July 2013

Dig Deeper on Productivity apps and messaging security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.