Don't bury your head in a security sandbox

Long-term software security requires better application development practices, not sandboxes

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.

Security iGuide

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.

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies