Security sandbox program: Defense-in-depth or layered vulnerabilities?

As children, many of us played in sandboxes: controlled play environments that enabled us to build castles safely without digging up the backyard. In computing, a sandbox serves a very similar function, only here, researchers and IT technicians are playing with bits, not grains of sand. In this tip, we'll discuss the concept of application sandboxing or security sandbox programs, including what they are, how they work and whether they add more vulnerabilities than mitigate. A sandbox operates by providing an isolated or confined space that functions similarly as -- but is not connected to -- the actual network. In this isolated space, programs and applications can be downloaded, unpacked and tested before they are migrated to the actual server, thereby (hopefully) preventing malicious programs from causing chaos on the network.

Originally designed for the development and testing of programs, sandboxes have evolved into a security tool capable of separating active programs and processes from the host system or local desktop. Thus, a security sandbox has become an efficient method for keeping systems safe from unverified and untrusted programs that could potentially wreak havoc on networks.
The average computer user may encounter an array of sandboxes on a daily basis. Google Inc.'s Chrome browser employs sandboxing to isolate JavaScript execution, HTML parsing and plug-ins. This is accomplished by running each tab in its own sandbox, thus separating Web applications from the user's machine. In early February 2011, however, Google fixed nine bugs in Chrome, including a sandbox-escape flaw. While details were provided regarding most of the bugs, Google was not so forthcoming in disclosing information about the sandbox vulnerability. This lack of transparency leaves questions regarding the security of the browser. If vulnerabilities are allowed to pass through the sandbox to their host system, malware could be installed and sensitive data could be at risk.
The popular Web service PayPal also utilizes sandbox technology to create a testing environment for merchants. The sandbox provides users with the opportunity to generate and manage mock accounts prior to actually implementing the service to accept Web transactions from customers. Problems, though -- specifically, cross-site-scripting (XSS) vulnerabilities -- have been reported.
In its most recent Flash release, Adobe Systems Inc. included a sandbox security feature to prevent Flash files loaded from the local file system from passing data to remote systems. While malicious hackers have been doing their best to break Adobe's sandbox, such features still stand as a potentially useful threat mitigation tactic.Computer and network forensic investigators may also benefit from using sandboxes. By giving examiners the ability to observe malicious executables as they unpack and execute in a "natural" environment, sandboxes could limit the likelihood that outside influences, such as other programs or services, will alter evidence. Theoretically, this all sounds amazing, but, in reality, it may introduce more

vulnerabilities.Sandboxes: Technology and use cases

Are corporations such as Adobe and PayPal actually making their software more secure by introducing a sandbox program, or does such a program simply add another potentially breachable layer? In IT security, defense-in-depth aims to layer different security approaches in an effort to improve the overall security posture. However, in this case, adding another layer likely means adding another permeable layer that could allow malware and hackers to penetrate the sandbox and access a computer.

The four questions security administrators must ask themselves prior to implementing a sandbox are:

■What types of threats are sandboxes the most effective at thwarting?
Understanding the capabilities and limitations of sandboxes is essential to knowing the best implementation and integration possibilities for sandboxes into an organization. Unrealistic expectations will only leave an organization more complacent and, therefore, more vulnerable.

■What threats are sandboxes incapable of detecting?
Sandboxes are unable to detect encrypted viruses or other malicious code, forcing network administrators to add further security measures and, consequently, more layers of complexity.

■What risks do sandboxes introduce?
Sandboxes introduce new vulnerabilities to exploit, such as potential stack overflow, access to native libraries on the host system, and other inherent flaws associated with using Java and C# coding. Further risks include the security measures, or lack thereof, within the digital sandbox itself.

■Is there an alternative to using a sandbox that could achieve the same results?
While sandboxes are useful for programmers to test the codes they have written in, relying on a sandbox to test unknown code is risky. Oftentimes it is safer to simply omit the extra software layer altogether. For instance, when the Adobe sandbox is in protected mode, some threats, such as monitoring keystrokes, may be avoided, but other risks, such as access to protected areas like the registry, may be elevated.

Potential vulnerabilities of sandboxes

A sandbox is divided into three primary compartments. These are: the core language interpreter, the standard libraries and the untrusted application code. Of the three compartments, the standard libraries, which contain routines to perform, such as network communication and cryptography, are the most vulnerable. This is directly related to the common practice of using Java or C# coding to write these libraries and the inherent flaws of those languages, such as stack-overflow vulnerabilities. In fact, C# not only possesses weaker security by marking sections of code as unsafe, but also permits simple access to native libraries on the host system.Many individuals may confuse a sandbox with a virtual machine (VM); this is probably because many organizations use VMs as sandboxes. Doing so may be suitable as added security for Web browsing on the typical home computer, but it is not recommended for testing suspicious programs or for use on systems where sensitive data is stored.
Due to the increased popularity of virtual machines in personal computing, for generating honeypots and as a general network security measure, black hat hackers are now writing malicious code to detect if a VM is being utilized. This type of malicious code can detect whether a virtual machine is running by looking for artifacts in the system's memory, running processes, registry and file system. It may even look for VM hardware and processing instructions. Therefore, using a virtual machine as a sandbox (or in any other security capacity) is very risky and only serves to deter the lower level -- or opportunist -- hackers who do not have the skills or tools to detect if in fact a VM is in use.

In closing, security sandbox programs are not a panacea. Sandboxing was developed to separate code from the host system; however, different security vulnerabilities and implications, as enumerated above, have inadvertently arisen. Thus, as with any security measure, risk assessment and mitigation are crucial when determining which security features to apply. Sandbox technology continues to not only find new uses and provide a multiplicity of benefits, but it can also lead to complacency and a false sense of invincibility. While defense-in-depth is a good strategy, it's also important to remember that, with each added layer, the number of exploitable vulnerabilities rises.

All forms of security have unintended consequences, and sandboxing is no different. Thus, relying on sandboxing alone to guarantee an application's integrity would be a serious mistake. Proper application security demands many different layers of security, all of which work together to provide a sturdy, multifaceted application defense posture. While sandboxing has potential when used properly, beware of the dangers; otherwise, effective applications, like the sand in that childhood sandbox of yesteryear, may slip right through your fingers.

About the authors:
Ashley Podhradsky, D. Sc., is an assistant professor in the Computing and Security Program at Drexel University. Dr. Podhradsky teaches and conducts research in digital forensics and information security. Her research has been recognized in academic conferences and journals within the U.S. and internationally.

Cindy Casey has an AAS. in Computer Forensics and completed her internship with the Montgomery Country District Attorney's Office's Computer Crime Unit. Ms. Casey, a student of Dr. Podhradsky, is currently enrolled in the Computing and Security Technology program at Drexel's Goodwin College of Technology and Professional Studies.