Sandboxing: Welcome to the dawn of the two-exploit era

Sandboxing: Welcome to the dawn of the two-exploit era

Summary: Sandboxing technology may help get the desktop exploitation attacks off the table so perhaps we can start to focus attention on the in-the-browser-walls attacks.


Guest editorial by Jeremiah Grossman

Exploitation of just ONE software vulnerability is typically all that separates the bad guys from compromising an entire machine. The more complicated the code, the larger the attack surface, and the popularity of the product increases the likelihood of that outcome. Operating systems, document readers, Web browsers and their plug-ins are on today’s front lines. Visit a single infected Web page, open a malicious PDF or Word document, and bang -- game over. Too close for comfort if you ask me. Firewalls, IDS, anti-malware, and other products aren’t much help. Fortunately, after two decades, I think the answer is finally upon us.

First, let’s have a look at the visionary of software security practicality that is Michael Howard as he characterizes the goal of Microsoft’s SDL, "Reduce the number of vulnerabilities and reduce the severity of the bugs you miss." Therein lies the rub. Perfectly secure code is a fantasy. We all know this, but we also know that what is missed is the problem we deal with most often, unpatched vulnerabilities and zero-days. Even welcome innovations such as Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) only seem to slow the inevitable, making exploitation somewhat harder, but not stopping it entirely. Unless the battlefield itself is changed, no matter what is tried, getting hacked will always come down to just one application vulnerability. ONE. That’s where sandboxes come in.follow Ryan Naraine on twitter

A sandbox is an isolated zone designed to run applications in a confined execution area where sensitive functions can be tightly controlled, if not outright prohibited. Any installation, modification, or deletion of files and/or system information is restricted. The Unix crowd will be familiar with chroot jails. This is the same basic concept. From a software security standpoint, sandboxes provide a much smaller code base to get right. Better yet, realizing the security benefits of sandboxes requires no decision-making on the user’s behalf. The protections are invisible.

Adobe adding 'sandbox' to PDF Reader to ward off hacker attacks ]

Suppose you are tasked with securing a long-established and widely-used application with millions of lines of insanely complicated code that’s deployed in a hostile environment. You know, like an operating system, document reader, Web browser or a plug-in. Any of these applications contain a complex supply chain of software, cross-pollinated code, and legacy components created long before security was a business requirement or anyone knew of today’s class of attacks. Explicitly or intuitively you know vulnerabilities exist and the development team is doing its best to eliminate them, but time and resources are scarce. In the meantime, the product must ship. What then do you do? Place the application in a sandbox to protect it when and if it comes under attack.

That’s precisely what Google did with Chrome, and recently again with the Flash plugin, and what Adobe did with their PDF Reader. The idea is the attacker would first need to exploit the application itself, bypass whatever anti-exploitation defenses would be in place, then escape the sandbox. That’s at least two bugs to exploit rather than just one. The second bug, to exploit the sandbox, obviously being much harder than the first. In the case of Chrome, you must pop the WebKit HTML renderer or some other core browser component and then escape the encapsulating sandbox. The same with Adobe PDF reader. Pop the parser, then escape the sandbox. Again, two bugs, not just one. To reiterate, this is this not say breaking out of a sandbox environment is impossible as elegantly illustrated by Immunity's Cloudburst video demo.

Adobe Reader X sandbox leaves 'residual risk' ]

I can easily see Microsoft and Mozilla following suit with their respective browsers and other desktop software. It would be very nice to see the sandboxing trend continue throughout 2011. Unfortunately though, sandboxing doesn’t do much to defend against SQL Injection, Cross-Site Scripting, Cross-Site Request Forgery, Clickjacking, and so on. But maybe if we get the desktop exploitation attacks off the table, perhaps then we can start to focus attention on the in-the-browser-walls attacks.

* Jeremiah Grossman is the founder and Chief Technology Officer of WhiteHat Security.

Topics: IT Employment, CXO, Security, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • not good enough

    This still assumes that the goodguys are smarter than the badguys, which is a dangerous assumption. And the badguys have the advantage of being on the attack, not playing defense. The better solution is to put the code you don't want hacked BEHIND HARDWARE. Incredibly simple. Less flexible? Definitely. But much of the code I run is YEARS old, so not a problem. It's a tradeoff. But let's face reality...the current approach of making EVERYTHING vulnerable to change by software, not just by the badguys but by stupid users, is clearly not working. Otherwise, why are we still taking about it?

    • Not so much "smarter"

      @gdstark13 It's not so much that one side is "smarter" than the other; it's that one side is more inclined to look for flaws than the other (and it would certainly be nice if the companies that make the SW could do a better job of it, but that's a different issue).

      One of the bigger issues is that many people believe that security software is a panacea, that they can do whatever they damn well please as long as they have the proper protection. What needs to be understood, both by security companies and by end users, is that security is a process. You have to exercise discretion in what you do online (e.g., don't open anything from someone you don't know, and be wary of anything from someone you do know).
      Third of Five
      • RE: Sandboxing: Welcome to the dawn of the two-exploit era

        @Johnny R

        No real argument with what you say, but I do have an issue with simply dumping the problem back on the users as so many do. You aren't going to re-educate all the grandparents out there. And you will NOT see an end to social attacks. The better solution is to simply improve the product. I don't accept the assumption that the customer will always need to be an amateur IT expert to use a computer, any more than you need to be a mechanic to drive an automobile. I believe that computer security will ultimately improve by simply making most of the code "bullet-proof" by securing it behind hardware. No amount of remote attacks can ever alter code protected by simple hardware write-protect. And while I realize that some users want the "latest and greatest" updates on everything, that's just not representative of the rest of the world. Many, many people are perfectly happy using older office products, browsers, and so on. The idea of trading shiny newness for stability is a fair proposition IMHO.

  • RE: Sandboxing: Welcome to the dawn of the two-exploit era

    Is truly effective sandboxing possible without limiting application functionality too much? Some applications are of no use unless they can read files, write files, print jobs, etc. Can an app be effectively sandboxed and still do what's needed?
    • RE: Sandboxing: Welcome to the dawn of the two-exploit era

      Taking acrobat reader as an example. You say it needs to be able to read files, but that's too broad. It doesn't need to read my email archives, or financial records, or the vast majority of other files on my system. My web browser needs internet access, but doesn't need to be able to talk to an IRC server. A well-designed sandbox is as big as it needs to be, and no bigger.
  • RE: Sandboxing: Welcome to the dawn of the two-exploit era

    "Sandboxing" the word badly coined for this sort of app, has been around for a long, long time I'm afraid. It's just that some are now finally being recognized as the good apps they are. Of those available to us, I like WiinPatrol the best, though while it's not perfect either, I find it catching things none of my other apps catch, including a host of malware finding apps that are run standalone and not in realtime.
    If you've got supersecret data, just don't connect it to the internet; make getting it to the 'net an intentional, purposeful activity separate from the oirginating servers/machine/whatever. That at least takes care of a large piece of the problem. And, it can be done rather easily.
  • not a new era...

    This isn't a new era, it isn't a new technology, it isn't a new idea. Keep your pants on, buddy.<br><br>Most Unix admins have been "Sandboxing" applications for years by using chroot jails combined with a least-privileges model. Sun took it a step further about 8 years ago by introducing Solaris containers. <br><br>The headline should actually be, "Sandboxing, Desktop Application Vendors Finally Realizing How to Write Secure Applications".

    As far as web-exploits, like SQL-injection and XSS... Those are separate concerns that publishers already need to worry about and that most intelligent professionals deal with. SQL injection would be a non-issue if more introductory webprogramming textbooks would encourage the use of prepared statement features, wherein the database driver takes care of escaping for you.
  • IE has had Protected Mode since IE7...

    "I can easily see Microsoft and Mozilla following suit with their respective browsers..."

    IE7 on Vista did this first with Protected Mode, long before Chrome. Now, you could argue that IE's Protected Mode doesn't go far enough, since you can still read stuff from the user's profile, and it's not executing in a separate logical desktop like Chrome is. But it still was there first.
  • RE: Sandboxing: Welcome to the dawn of the two-exploit era

    I'll kick sand in your face.
  • RE: Sandboxing: Welcome to the dawn of the two-exploit era

    Look into Geswall + Sandboxie. I think using these 2 programs together is the safest solution.<br><br><a href="" target="_blank" rel="nofollow"></a><br><br><a href="" target="_blank" rel="nofollow"></a>
  • RE: Sandboxing: Welcome to the dawn of the two-exploit era

    Might as well put MS Products in QuickSand, it's such a rotting, sinking, stinkpot of a Company.