Making Client-side Java Secure - with Bromium vSentry

Making Client-side Java Secure
with Bromium vSentry®

Making Client-side Java Secure
Client-side Java has become somewhat of an IT pariah, primarily as a result of the growing
list of Java vulnerabilities and updates which mushroomed over the last year. Apple and
Google have advised users to disable browser plugins for Java and Microsoft FixIt blocks
Java from Internet Explorer, to prevent drive-by attacks. Even the US Department of
Homeland Security has warned users to disable client-side Java.

While these responses are rational, they are only relevant in a consumer context, and few
consumer websites today rely on Java. By contrast, enterprises are heavily dependent on
Java, for both client and server applications.

If you’re in enterprise IT, you know Java is here to stay.

The good news is that Java can be made completely secure. So you can continue to use
existing enterprise applications, and not fear the consequences of a mistaken click by a
user or a rogue attack by a compromised website.

Why Do Malware Writers Target Java?

Enterprise IT Pros know that they depend on client-side Java, and sometimes on specific
versions of the Java Runtime Environment. A company might be targeted using Java based
attacks from the web, because it has (or depends on having) an out-of-date version of the
JRE on its PCs so that users can access enterprise applications, such as the Oracle ERP suite.
But companies are just as dependent on other legacy applications, including old versions of
browsers and .NET, and on vulnerable versions of Windows.

So why the concern about Java?

Perhaps it is the fact that attackers always look for the weakest point in a target’s defenses.
The powerful features available to attackers within the JVM have withstood the best efforts
of the security industry to find a good defense. Numerous efforts have been made to find a
reliable way to detect “malicious” Java code with little success. Obfuscation, polymorphism,
code injection, the list of techniques available to attackers to hide their intentions is large
and seems to grows larger every month.

Java, like all complex application and OS software environments, is vulnerable because it
offers a large attack surface. In addition to offering all of the key functions and services that
any OS needs to offer a programmer, it presents a runtime environment that is consistent
across all supported OS platforms, for both clients and servers. Java is therefore a perfect
target for the malware writer: complex, and with many dependencies on third party
components: the OSes and their UI frameworks, libraries, browsers, web servers (to
distribute the applications) and of course the complex JVM runtime itself, which has to
support floating point arithmetic and other complex functions. The problem becomes
exacerbated if you consider non-Oracle JVMs. In other words, managing the security of Java
is not only an Oracle problem.

Unfortunately, Java’s many benefits have also made it a target because of its ubiquity and
platform independence. It meets the economic needs of malware writers: One can target a
massive number of deployed systems with one piece of malware, or single out a specific
high value target with confidence because the JRE is the same on all supported platforms –
whether Windows, Mac, or Linux. A single compromise has and will continue to succeed
across platforms.

But apart from its ubiquity and current popularity with hackers, Java is not particularly
more insecure than other commercial applications, nor is Oracle particularly remiss in its
security methodology. All software is vulnerable. And if suddenly the JRE were perfectly
secure, would this end the endpoint security woes we face? No. The vulnerable code base
on PCs includes everything, from the OS, to apps and their plugins. As soon as Java has
been patched sufficiently for a while, attackers will find other ways in. In other words, the
problem isn’t Java.

User Training Doesn’t Solve the Problem

Is the problem the “You” in “User”? Every one of us makes the occasional mistake, and IT
Pros are no better at avoiding missteps than the general user base. Yes, training may
reduce mistakes, but won’t stop all mistakes. There are many documented
failed attempts to train users not to click on “seemingly unsafe” links or files, and so we
must assume that user training will never succeed since the attacker is always a step ahead
of the trainer. So, (unpatched) Java, and un-trainable users are with us to stay.

Endpoint Protection and OS Vendors Can’t Help

OS vendors can only distribute patches when new vulnerabilities emerge. That doesn’t help
to protect the end point from attack, and leaves enterprises vulnerable for months at a
time. And Endpoint Protection vendors find themselves in a bind when it comes to Java. A
Java applet is a binary program that may or may not be signed. While it is possible to
restrict the JRE to running only signed applications, it is also possible for malware writers to
steal code signing certificates to forge the authenticity of their code.

Beyond this, traditional legacy Host-based Intrusion Prevention Systems (HIPS) can at best
recognize a particular applet as malicious, but once it is running, they are cannot block or
stop it, which is among the reasons Java is so effective for the attacker. Until now, the
security industry has had nothing more useful to offer than advice on how to un-install,
or update the Java plugin. Apple removed Java from Safari last October, and as previously
mentioned, Microsoft FixIt now blocks Java from IE.

For its part, Oracle has repeatedly promised to fix Java once and for all, and has embarked
on a series of modifications to how Java applications work, to try to contain the problem.
Nandi Ramani, who leads the software development team building the Java platform, wrote
the following in a recent blog entitled “Maintaining the security-worthiness of Java is
Oracle’s priority”:

   In JDK 7.2, Oracle added enhanced security warnings before executing applets with an
   old Java runtime... In JDK 7.10, Oracle introduced a security slider configuration option,
   …. Further, with the release of JDK 7.21, Oracle introduced the following:

1.  With this update … users can prevent the execution of any applets if they are
               not signed.
            2. The default plug-in security settings were changed to further discourage the
               execution of unsigned or self-signed applets. This change is likely to impact most
               Java users, and Oracle urges organizations …to sign [their] Applets
            3. While Java provides the ability to check the validity of signed certificates … the
               feature is not enabled by default because of a potential negative performance
               impact. …In the interim, we have improved our static blacklisting to a dynamic
               blacklisting mechanism …*

*https://blogs.oracle.com/security/entry/maintaining_the_security_worthiness_of (underlines added by Bromium)

Oracle’s approach is rational, but does not address the root problem, namely the fact that
we must assume that all software will always be vulnerable. Instead, the aforementioned
approach:

      1. Puts the onus on the user to do the right thing
      2. Makes Java harder to use, and therefore complicates the user experience
      3. Attempts to leverage black-listing for known malware to try to block new attacks –
            an approach that has consistently failed in the anti-virus industry.

Bromium vSentry Makes Java Secure

Bromium vSentry eliminates security challenges from Java and other vulnerable software. It
protects the endpoint from all untrustworthy content and applications while ensuring that
users enjoy an unchanged native user experience. vSentry allows:

      •     Today’s vulnerable applications & plugins (Flash, Java, Silverlight, Chrome, Firefox, IE,
            Word, Powerpoint, Excel, PDF, media etc) to run as intended by the vendor,
      •     New mobile-centric, cloud based applications for consumers or enterprises, to
            deliver a user experience that fully empowers the user, and
      •     Offers complete, hardware based security.

Bromium vSentry uses hardware isolation to protect the system from all malware – known
and unknown. Every untrusted application or file is processed in an independently
hardware-isolated micro-VM which will defeat any attack, by design. The attacker cannot
gain access to enterprise networks or data, or persist an attack on the endpoint. Moreover,

the attack will be automatically discarded as soon as the user closes the task window (or
the browser tab).

No remediation. No change to the applications or to the end user experience. And if the
endpoint is attacked, Bromium LAVA will provide live attack visualization, with complete
forensic analysis - delivered instantly to the SOC.

Bromium micro-virtualization is the only absolutely reliable way to defeat all advanced
malware, including Java based attacks. The Microvisor hardware-isolates each untrusted
user task within a micro-VM, using CPU features developed for virtualization. The
Microvisor hardware isolates the execution of each task using Intel VT, protecting the OS
and its file system, the network infrastructure, and all valuable data from malware.

How does vSentry manage both enterprise Java applications and malware delivered via the
web or untrusted documents?

Each browser tab is opened in a separate micro-VM, which is a hardware-isolated runtime
environment with highly restricted access to networks, files and the desktop environment.
In the example below, a compromised micro-VM (in this example a FAKEAV anti-virus attack
crafted in Java) is independently and separately isolated from all other tabs in the browser
– including the Oracle ERP application.

As the user types into the ERP application, all user input is directed solely to that task, and
not to any other tasks on the desktop, including the FAKEAV browser tab. The attacker,
whose Java based attack “succeeded” in the highly restricted environment of a micro-VM,
has no access to the enterprise network, or to any enterprise data (the file system) or to the
desktop as a whole, and therefore cannot persist his attack. As soon as the user closes the
browser tab, the entire task will be discarded, naturally remediating the PC from the attack.

The protection afforded by a micro-VM is so substantial that it malware would need to
break the CPU in order to compromise the system. The entire code base of the microvisor
and all code that could be exploited by malware in an attempt to escape the micro-VM
containment, is O(100KLOC). And even if this code is compromised, the system is designed
to fail safe – untrustworthy tasks may not execute, but the user will still have full access to
their IT provisioned LOB applications (including enterprise Java applications), and will have
the full protection of traditional AV. By contrast, any failure to detect, on the part of AV, or
any break out from the sandbox will cause complete system compromise. The Bromium
architecture is designed assuming compromise.

Conclusion

Micro-virtualization allows Bromium vSentry to offer protection that is tens of thousands of
times more resilient than any existing protection mechanism – essentially making it too
expensive for an attacker to attempt to compromise the endpoint. It leverages three key
innovations:

   •   Hardware isolation: drastically reduces the code base required for isolation. To
       break out of its isolated task environment (a micro-VM), malware would need to

break the CPU’s hardware isolation designed for virtualization: Intel VT - in effect
                    breaking the CPU.

               •    Granular task isolation in micro-VMs: Protects kernel and application
                    computation at a granular level. Each independent Java application runs in its own
                    separately isolated micro-VM, independent of all others. Each has a highly restricted
                    environment that prevents access to enterprise networks or data, while still
                    preserving an intuitive, native user experience.

               •    Micro-VM Introspection: affords insights that are not available to in-OS detection
                    methods, by taking advantage of the hypervisor’s privileged role in the system. This
                    permits live attack visualization and analysis without false positives, and provides a
                    full kill-chain for forensic analysis, including signature generation for malware
                    payloads.

Bromium HQ                                 Bromium UK Ltd
20813 Stevens Creek Blvd, Suite 150        Lockton House
                                                                                              For more information refer to
Cupertino, CA 95014                        2nd Floor, Clarendon Road
                                                                                                        www.bromium.com
info@bromium.com                           Cambridge CB2 8FH
+1.408.598.3623                            +44 1223 314914
                                                                                           Contact Us: sales@bromium.com