Cisco Blogs

It Crawled Out of the Sandbox

April 27, 2011 - 0 Comments

Security and functionality have lived on opposite ends of the spectrum since the dawn of time. The door with no lock has always been easier to use than something with multiple chains and dead bolts. Of course, the unlocked door has always been easier to open for those who may want to do bad things.

One idea that promised to offer the ease of use equal to that of the open door combined with the security of the deadbolt was the “sandbox”, a restricted area within which the program could run; however, in the case of Java 1.0, many activities such a reading or writing to a local drive, starting new processes, or opening new network connections were prohibited. The sandbox may have been too successful, or at least too restrictive, as developers found it difficult to do many useful things within the confines of the early sandbox. This of course lead to a somewhat more permissive sandboxes, which enabled developers to do more, but which also occasionally allowed unfortunate things to come crawling out of that sandbox.

The desire for more functionality is by no means exclusive to Java, take the PDF for example. Originally a more or less static way of presenting formatted documents—including text, graphics, and layout information—the desire to enable more interactivity and greater functionality lead to the PDF learning new tricks. It started with forms, then JavaScript, and ended up with the PDF being the most exploited launchpad for malware until being passed by Java around June of 2010 (Cisco SIO 2010 Annual Security Report, 2010, page 23).

While everyone agrees that having a cross-platform vehicle for sharing and displaying highly formatted documents is a good thing, it was also clear that the additional functionality, which had been gradually creeping into the Acrobat platform, was creating security challenges that were starting to make people consider alternatives.

Thus it was in 2010 that Adobe added a sandbox to Adobe Reader X and Adobe Acrobat X. The Adobe sandbox was structured so that PDF processing, rendering, and such would all happen in the sandbox. Operations that required access to something outside the sandbox had to go through a proxy or broker process. The Reader sandbox joined the Flash Player sandbox, which was introduced in 2005 in Flash Player 8 – the goal of both being to permit useful functionality while providing needed security.

Sadly, finding the right mix of functionality and security, even with sandboxes in play, can be a real challenge. Recently Adobe issued another Security Advisory for Flash Player, Adobe Reader, and Acrobat X about a vulnerability that could allow an attacker to cause a crash and potentially take control of an affected system. It is interesting to note that according to Adobe, using protected mode would prevent this particular exploit from working.

What conclusions can we draw? Well, in theory the idea of the sandbox is sound. In practice, it can be sound too. However, companies like Adobe face tremendous challenges. Market pressures demand increasing functionality. The number of platforms on which consumers demand support is constantly growing as is the complexity of delivering such a large number of features and capabilities across those platforms. While it is easy to point fingers and complain of vulnerabilities, it is perhaps best to understand that in situations where the balance between safety and functionality is complex there is going to be opportunities to enhance the balance on both sides of the equation. While it is fairly certain that the bad guys will find holes, it is equally certain that those holes will be patched. It is also possible to take a stance like the Google Chrome team and run the Flash Player in its own sandbox, just like they do for HTML and Javascript.

Of course, if something can crawl out of one sandbox, it might be able to crawl out of two. In the meantime, Cisco SIO has a great deal of information for you on security. The 2010 Security Report mentioned earlier is one example. Another is the Cisco 4Q2010 Global Threat Report.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.