Best Defense?

Despite managed execution frameworks, developers aren't sandboxing their application code.

When the first Java apps emerged more than a decade ago, they helped make IT professionals aware of the security threats posed by applications originating beyond the firewall. Today, security experts are concerned that too few dev shops are properly employing techniques like sandboxing to limit the reach of code running on their systems.

Sandboxing, a security feature of managed applications designed to isolate untrusted or untested code, could vastly reduce the threat posed by insecure or malicious applications. Yet many shops often fail to build sandboxing into their development process, whether in an effort to meet deadlines or due to the lack of recent calamities that rival the infamous 2003 Slammer worm in severity. It's not clear how many organizations actually sandbox their code as a matter of policy, but anecdotal evidence suggests very few do so.

"I would be shocked if it was 1 percent" of all enterprise developers, says Gary McGraw, CTO of Cigital Inc., a Dulles, Va.-based consulting firm specializing in software risk management and data security.

Interviews with attendees at last month's QCon conference in San Francisco, a gathering of software developers and architects, suggests that there's little enthusiasm for sandboxing among developers. "I know I should do it, but it's time-consuming, and no one is really asking me to," says one attendee who asked not to be named.

This widespread failure to sandbox code is a disaster waiting to happen, warns Dinis Cruz, chief security evangelist of the Open Web Application Security Project (OWASP), a consortium focused on finding and fighting the causes of insecure software ( "We're not putting enough resources and investment into sandboxing technology," Cruz says. "The consequence is that developers aren't taking sandboxing seriously anymore."

Cruz, who also leads the OWASP .NET Project, and is the main developer of several OWASP tools, is a consultant and trainer who specializes in penetration testing, ASP.NET app security, source-code security reviews, reverse engineering and security-curriculum development. He's well-known at conferences and trade shows for showing attendees how to bypass the built-in security mechanisms of the .NET and Java runtimes.

Cruz is on something of a mission to get developers-especially ASP.NET developers-to take sandboxing seriously. This venerable managed-code security mechanism, designed to isolate untested code and code from unverified third parties and untrusted users, has fallen into disuse, and Cruz believes that trend is a harbinger of disaster.

"The problem is we're building a world where all the code that we run on our Web sites has the power to access all our assets from our desktops and servers," he says. "From a security point of view, this is very bad."

Fresh Worries
Cruz is especially concerned about the new Web-app frameworks-Adobe's AIR, Sun's JavaFX and Microsoft's Silverlight. "If you look at the new frameworks, they're all removing the sandbox," he says. "I like the analogy that they're all jealous of the desktop application that has all the power in the world. They basically now are saying, 'hey, the new paradigm is just the desktop application.' The user installs it, clicks yes, so the vendor is covered, and then those things have access to all the user's resources."

Sandboxing has long been a feature of the Java development environment. It was originally designed to limit the access to memory of Java applets sent to a browser. In the .NET Framework the sandboxing feature is called Code Access Security. It's designed to allow networked applications to trust code at varying degrees, depending on such factors as where the code originates and other aspects of the code's identity. It also provides a mechanism for enforcing the varying levels of trust, which makes it possible to minimize the amount of code that must be fully trusted to run.

Cruz advises developers working in the .NET Framework 1.1 to write apps that can be executed in secure Partially Trusted .NET environments.

Sandboxing employs what is known in security circles as the principle of encapsulation, explains Cigital's McGraw. "When you run code inside a sandbox, if that code is exploited by an application-based attack, the attack doesn't gain complete control of the machine," he says. "This, of course, is a very good thing."

McGraw says it's clear that using a language like Java or taking advantage of the .NET CLR is something developers should do. "It would be even better if the developers and architects would take advantage of the sandboxes that are built into both of those models," he says.

The Decline of the Sandbox
McGraw confesses to contributing, himself, to the decline of the sandbox. Early in his career, he gained notoriety in security circles by punching holes in the Java sandbox.

"Unfortunately, people used that as a reason not to move to managed code, and to continue to use C and C++," he says. "But it has become clear that it's easier to avoid stupid bugs if you use a modern language and a modern framework. Everyone understands that now, and we should just get rid of C and C++. But also, if you use managed code properly, you can get rid of some flaws that are harder to work on. The best of the best are going to be doing that."

Developers routinely ignore the powerful security features built into .NET and Java, says Brian Chess, chief scientist and co-founder of Fortify Software Inc., a Palo Alto, Calif.-based provider of enterprise application security solutions.

"If there were some easy, take-a-pill kind of solution to the software security problem, you'd better believe everyone would want to do it," says Chess. "To use the sandbox, you've got to know the difference between what your code is supposed to do and what it's not supposed to do. And that is hard."

McGraw agrees: "This is not a simple process," he says. "You have to think carefully about the kinds of privileges your code needs, which is something you don't have to worry about if you don't use a sandbox. And there's a lot of institutional momentum to write unconstrained code. Enterprise developers have a lot of experience doing that, and when you have more power it's easier to get things done. To employ sandboxing, you might actually have to change the way you code. And that's not easy to get anyone to do."

McGraw points out that even Microsoft didn't use .NET, the CLR and managed code when it wrote the Windows Vista operating system. In fairness, he adds, the libraries required to write an operating system were not available at the time with .NET. But it was, he says, an opportunity missed.

Know the Code
What should Microsoft do to advance the sandboxing cause?

"I think Microsoft is more interested right now in giving developers what they want, rather than what they ought to be using," McGraw says. "The developers are making the choices, and Microsoft seems to prefer to remain agnostic about those choices. The only thing they could do would be to cheerlead more for the better way."

Cruz gives Microsoft credit for listening to his message-and even agreeing with it. But he says the company's customers simply aren't demanding this level of security, and the developers don't like the extra work it takes to safely contain malicious code.

Although Microsoft is stepping up its efforts to promote more secure computing with new software releases, it has had little to say specifically about sandboxing. The company did, however, take an additional step last month to encourage developers to become more security conscious.

Microsoft has joined a group of leading technology companies to form a non-profit organization called the Software Assurance Forum for Excellence in Code (SAFECode, SAFECode was formed, says Steve Lipner, Microsoft's senior director of security engineering strategy, to identify and promote best practices for developing and delivering more secure and reliable software, hardware and services. Along with Microsoft, the group's membership includes EMC Corp., Juniper Networks Inc., SAP AG and Symantec Corp.

"We believe there's an important need for the IT industry to come together in an organized way and identify proven practices that can be shared to increase trust in IT products and services," Lipner says. It's not clear to what extent, if any, the group will address sandboxing.

Microsoft security architect James Whittaker acknowledges that sandboxing is an eminently useful security component of the managed code model. But he points out that, his company's efforts notwithstanding, it's not exactly a universal model.

"There's no question that the proliferation of managed code has not been as fast as we had hoped," says Whittaker. "The majority of server-type apps are not using managed code, even though there are certain classes of security bugs that are completely closed by it. With a few billion users and a half a billion installations, you can't just go around re-writing everything."

So is Cruz creating a tempest in a teapot or is he on to something? Johannes Ullrich, chief research officer at the SANS Institute (, a Washington, D.C.-based computer-security research and education organization, says sandboxing is a "must do," particularly for new application design.

Johannes Ullrich"Virtualization is an extension of sandbox technology. And I think it's behind an increasing focus on putting more 'sandboxing' and things like mandatory access control into kernels."
Johannes Ullrich, Chief Research Officer, SANS Institute

"It makes software development more complex, but in a good way," he says. "It forces [developers] to think about what kind of resources they need. Any resources they need from the software should be part of the sandbox. If you don't do the sandbox, you can lose track of what your application needs to run."

Ullrich is responsible for the SANS Internet Storm Center (ISC) and the GIAC Gold program. He founded in 2000, which is now the data-collection engine behind the ISC.

Cruz on Code Security

Dinis Cruz likes to make developers uncomfortable. A frequent guest on trade-show conference panels, the pony-tailed security consultant with the Portuguese accent and the London address often shows attendees just how easy it is to bypass the built-in security mechanisms of the .NET and Java runtimes. During a recent visit to the United States, he took some time to talk with Redmond Developer News about the challenge of convincing developers to build secure .NET apps and the near death of the sandbox.

RDN: In a nutshell, what's your biggest security concern?
Cruz: We're not putting enough resources and investment into sandboxing technology. The consequence is that developers aren't taking sandboxing seriously anymore.

Both .NET and Java allow for the creation of a sandbox, which can be enabled and disabled. The problem is, everyone disables it. I think that about 99 percent of the code out there runs with Full Trust with no sandbox-and I think I'm being generous with that 1 percent.

RDN: Why is that such a problem?
Cruz: The problem is we're building a world where all the code that we run on our Web sites has the power to access all our assets from our desktops and servers. From a security point of view, this is very bad.

RDN: Your favorite conference demo seems to be something you call "rooting the CLR." What is that?
Cruz: This is one way to expose the dangers of Full Trust ASP.NET code. I show how, with Full Trust, I can load some .NET code and change the framework behavior.

RDN: For example?
Cruz: One thing I was able to do was put a quick patch on a CLR [the core runtime engine in the Microsoft .NET Framework for executing applications] that disabled Strong Name verification. I just patched the actual .NET Framework and managed method that did that check, so then I could load and manage a sort of temporary .NET assembly.

The problem is, if you're running Full Trust, it's the same as writing a C++ assembly in there. There's no isolation within that process. On ASP.NET, that means that every third party a company will use has the power to actually change the framework itself and put in backdoors and all kinds of vulnerabilities in there that the framework won't protect against.

RDN: If this is such a problem, why aren't Microsoft and Sun doing something about it?
Cruz: I've argued with Microsoft quite a lot about this, and they always listen and they usually agree with me. But their clients aren't demanding it, and the developers don't like putting in all the extra work that it takes to safely contain malicious code, or benign code that could be executed in a malicious way. So, not much gets done.

Also, the attackers are not exploiting it. It's a cozy world right now where the guys writing the software don't want the hassle of writing secure applications, because it's more work, and the users aren't aware of it, so they don't complain about it, and the vendors don't want to code that way.

-- J. W.

The chief impediment to a renewed adoption of sandboxing in most development organizations, Ullrich suggests, is a nearly universal bias for speed. "Meeting a deadline is usually more important than application policy," he says. "The 'best' developer is the one who can turn out the most lines of code and the most features in the shortest amount of time. The staff, and to some extent the customers, are so used to broken applications that they don't really complain anymore."

Ullrich suggests that the new proliferation of virtualization technology may fuel a resurgent interest in sandboxing. "Virtualization is an extension of sandbox technology," he says. "And I think it's behind an increasing focus on putting more 'sandboxing' and things like mandatory access control into kernels." He points to chroots, which are used in Unix systems as a preemptive way of containing unprivileged attacks, and Mac OS X Leopard's new automatic sandbox feature, as examples.

A common excuse among developers for not using sandboxing technologies, Ullrich observes, is that sandboxes don't prevent bugs. "And that's true enough," he says, "but they may very well prevent or limit the impact of an exploit."

Still, Cruz is clear that he doesn't want to put the sandbox onus on developers. "I don't believe that it's the fault of the developer," he insists. "I think they're too often used as the scapegoats in all this."

The Road to the Sandbox

So how do dev shops hope to get to there from here? Experts provide some opinions:
  1. Make the move: Wherever possible, move development to mature, managed frameworks like .NET and Java, and take advantage of their sandboxing facilities when writing code. Also move to up-to-date languages and IDEs to gain access to streamlined tooling.
  2. Know thyself: Conduct a thorough code review and determine what applications currently enjoy wholesale system access, but simply do not need it. Get a detailed understanding of how code works with system resources and other software.
  3. Fix on the fly: Plan ahead to re-work code with sandboxing in mind, whenever a maintenance or upgrade cycle comes around. Introduce a rolling sandbox initiative into your software development lifecycle.
  4. Test aggressively: Introduce automated testing and penetration testing into the QA cycle to smoke out vulnerabilities and to ensure that newly sandboxed applications will work and respond as expected.
-- Michael Desmond
comments powered by Disqus

Reader Comments:

Add Your Comment:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above