Don’t bury your head in a security sandbox

Adobe will employ a new sandboxing technology in the next version of its oft-targeted Reader in the name of hardening security. However, the effort won’t make Reader more secure in the long run — and likely not even in the short run. I’m a big believer that the best predictor of future behavior is past behavior, and if you look at the two-decade history of security sandboxes, you’ll see they all eventually failed big.

The best example of failed sandboxes can be found in Java, which used an especially locked-down sandbox from the very beginning. In fact, it was so secure (no long-term writes outside the sandbox) that it proved too locked down. Nobody could use it to develop any substantial apps. To save a game score or spreadsheet, you needed long-term storage.

[ Master your security with InfoWorld’s interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter.]

Sun then developed a more granular model in SDK 1.2, which involved asking users for permissions to do things outside the sandbox and allowed applet digital signing. This model proved to be too complex for users and developers alike, and it never caught on. With both sandbox models, Java has had well over 100 critical security vulnerabilities, and it continues to be patched on a regular basis, even though Sun has had more than 15 years to perfect the sandbox.

Google’s Chrome browser has one of the best security models of the major browsers, and it includes a security sandbox. During the last two CanSecWest hacking contests, Chrome has been the only tested browser left standing. The hacking experts often credited Chrome’s security sandbox for its seeming impregnability. In reality, though, Chrome is hackable; it just doesn’t get hacked a lot in real life.

According to security firm Secunia, the Chrome browser has had somewhere around 100 reported vulnerabilities since its release in Feb. 2009. About one-third of the vulnerabilities would have led to system access. Thirty percent of vulnerabilities in Google Chrome 3.x would have led to sensitive information being released, and 20 percent would have allowed a hacker to bypass security access controls. The latest release, Chrome 5.x has slightly fewer sensitive information and access controls bypass stats, but still holds at nearly one-third of exploits allowing system access. Though I’m sure the sandbox is reducing the damage of many of the found exploits, the numbers are telling.

There are specialized browser lock-down apps available, such as ZoneAlarm’s ForceField or Sandboxie, a product space I reviewed a couple of years ago. My conclusions haven’t changed: There are some good products in this category. In fact, I think all of the competitors would stop significant amounts of malware. But none of the products would stop everything, and they certainly aren’t the solutions in the long run. If a particular solution became wildly popular, it would get hacked as frequently as the original application. Hackers would find ways around the defense solution, as they do antimalware scanners today.

Each additional software product — including stand-alone sandbox products — contains its own security vulnerabilities, just like today’s routers, firewalls, and security appliances. In the long run, sandboxes just become the target for attacks.

My long-held beliefs about sandboxes might surprise some readers, because one of the biggest new security features in Microsoft Office 2010 is a limited emulation sandbox environment called Protected View for newly opened documents. (Note: I’m a full-time employee of Microsoft.) For documents originating from a nonlocal source, the file is first opened in a very restricted environment. Users must click on a button labeled Enable Editing to open the document in the full Office environment.

The limited environment disables scripting, macros, embedded links, and other “active” content. Documents opened in Protected View are certainly less likely to compromise the underlying system. A lot of smart people worked hard to make it a more secure place to open documents, including David LeBlanc, one of the sharpest antimalware guys in the world.

Do I have a problem with Office’s sandbox, too? No — but I think it will face the same challenges as any other sandboxing solution. For one, today’s malicious social engineering is more than smart enough to get unsuspecting victims to click on the Enable Editing button. The bad guys have been able to persuade us to run unneeded macros and scripts and to install entire software programs. So why would a simple button would get in the way?

But the real reason that I feel good about Office’s new security has little to do with the sandbox and more to do with everything else. It has undergone years of Microsoft’s Secure Development Lifecycle (SDL) reviews.

I believe in SDL even more than sandboxes. Instead of putting faith into a security wrapper shell, what we all should be doing is more secure development. SDL means more than code reviews — although it includes plenty of that. It means more secure defaults; for example, does Adobe Reader need JavaScript enabled and callable by default? It means not using old APIs and functions known to be commonly involved in exploits. At Microsoft, dozens of APIs and functions have been declared banned. If they end up in code, they’re caught and removed before getting out of testing. SDL means making sure to use all the memory protections provided by the underlying operating system to prevent buffer overflows. Many very popular applications still do not utilize these free protections. SDL means creating threat scenarios and mitigations.

I don’t want to say that sandboxes don’t offer any security improvements. They do, at least for the short term. But better long-term security doesn’t come from sandboxes. It comes from making the underlying code more secure in the first place. And if I have to expend my resources to better secure my environment, I’d rather focus on long-term solutions than short-term shims.

This story, “Don’t bury your head in a security sandbox,” was originally published at InfoWorld.com. Follow the latest developments in security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com.