Java sandboxing could thwart attacks, but design may be impossible

Basic Java sandboxing has been around since 1995, but flaws in the Java virtual machine are highly targeted. Experts are calling on Oracle to do more.

Cybercriminals, buoyed by automated attack toolkits, are increasingly taking advantage of Java, targeting known Java vulnerabilities and discovering zero-day exploits. Experts say the onslaught will continue until more Java protections can be deployed by Oracle, but adding them around the programming language's engine is no easy matter.

Adding a second sandbox around the permissions system called the Java sandbox will surely make Java safer; it's just that it is hard or even impossible to do so.

Michael Schierl, software developer, Java expert

Developers at Sun Microsystems Inc. sought to put Java security measures in place to protect the Java virtual machine (JVM), the main engine that runs Java applets, long before attacks became commonplace. Sun, which was acquired by Oracle Corp. in 2010, created Java sandboxing restrictions to protect Java applets in 1995, isolating them from accessing critical processes in the browser or the file system.

Unlike Adobe Systems and the browser makers, which are building sandboxing protections around applets that run inside the browser, Oracle promotes the use of Java for building full-fledged desktop applications, which can write to arbitrary directories, said Michael Schierl, a software developer and Java expert based in Germany. This, he said, makes the process of adding defensive mechanisms for today's attacks much more complicated.

"Adding a second sandbox around the permissions system called the Java sandbox will surely make Java safer," Schierl said, it's just that it is hard or even impossible to do so."

Java has a vast trusted code base, Schierl said, referring to the amount of code that is inherently trusted by a client machine running a Java program. This enables a program to read configuration files and the registry, store data to cache directories and other functions.  To prevent the original sandbox from terminating normal Java applets, Schierl added, these "safe" functions would have to be whitelisted in a second sandbox.

Automated toolkits are fueling most of the attacks that exploit Java flaws. BlackHole and other toolkits make the process easy and systems without the latest patches installed face the most risk, experts say. But even fully deployed systems can be targeted.

Just this week, researchers discovered two Java zero-day vulnerabilities in the latest version of the programming language. Exploit code targeting the vulnerabilities, which is rated extremely critical by Danish vulnerability clearinghouse Secunia, is publicly available. Attackers can use the flaws to bypass restrictions, install a dropper and remotely control data stealing malware using a variant of the PoisonIvy Trojan.

Software security expert Gary McGraw, CTO of Dulles, Va.-based Cigital Inc., said the impetus should be on Oracle engineers to do a better job finding and correcting flaws in the Java virtual machine.  Today the Java is maintained by Oracle; the Redwood Shores, Calif.-based vendor has not responded to an interview request. The company also has not yet acknowledged the latest zero-day flaws or the publicly available attack code.

"It would be better for everybody if the Java virtual machine sandbox was just repaired," McGraw said. "The security mechanisms designed into Java are not so terrible; they are complicated and they have to be implemented exactly right. And exactly right turns out to be real hard."

Hundreds of millions of lines of code in Oracle’s codebase are written in Java, noted Eric Maurice, director of software security assurance at Oracle in a blog entry on Java security in February.  Maurice said Oracle had added development staff dedicated to Java security, and that additional code-scanning tools were adopted to detect and address vulnerabilities.

"With these new resources available to them as a result of the Oracle acquisition, the Java development team is weeding out security bugs in Java, and is looking at ways to further improve the security posture provided by Java to its users," Maurice wrote.

Java's age, complexity and install base make it a very attractive target for attackers, said Wolfgang Kandek, CTO of Redwood City, Calif.-based vulnerability management vendor Qualys Inc.  Kandek said Oracle could restrict the resources the JVM uses or request permissions, but additional restrictions would likely not be very practical.

"Oracle acquired a huge code base; a very successful code base and they have to work through the problems that come with it," Kandek said.  

According to Kandek the most practical solution for enterprises is to control where Java is running and only run it when necessary. Enterprises IT teams can use registry zones to implement tighter restrictions, he said.

This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close