This white paper provides a general understanding of how Java operates in the browser, the risks it presents, and identifies best practices and advice on how to reduce those risks.
The Java development platform provides a system for creating application software and deploying it across multiple operating systems and hardware architectures. Originally designed by James Gosling and Sun Microsystems, and now owned by Oracle Corporation, it was intended to allow developers to write applications once and run them anywhere. Java was released in 1995 and has become one of the most popular programming languages in use today, according to reports by the Redmonk and TIOBE Software language trackers.
Java applications, like any application, are installed and executed by the user and have as much privilege as the user running it. These applications can range from desktop text editors and games to back-end server software.
Signing an applet with a certificate signed by a CA attempts to create a layer of trust and comes at a premium, due to the need for the developer to purchase the certificate. This trust is built into the browser and JVM, and by default allows an applet to run unrestricted (no sandbox) and without prompting, provided the certificate is valid. A certificate can be deemed invalid if it has expired, or the host name delivering the applet does not match the host name the applet was signed with.
The purpose of the sandbox is to limit the full power of Java when unsigned applets are launched. However, restricting access to components is not a simple task, especially with the complexity and power inherent in Java. Every year, numerous holes in the sandbox have been discovered and leveraged to break out of the protected environment, giving access to more dangerous commands. Once the sandbox is compromised, the untrusted code may gain access to a number of previously restricted commands, and have the capability to do such things as download additional components (malware), alter the file system, or launch new processes.
With continual successful attacks on the sandbox, it has become very important for the user to limit Java applets executing from within the browser. There are web applications that still rely on Java availability from within the browser, so completely removing it is not always an option, especially in corporate environments where internal applications may rely on it.
As with any system, disabling and removing unused and unneeded components will reduce the attack surface. That is certainly true in this case, and the best defense against any current and future Java vulnerabilities is to make sure it is completely disabled in the browser. Starting with version 1.7_10 (JDK 7u10), disabling Java in the browser has become as easy as un-ticking a check box on the Security panel in the Java Control Panel. Note that a browser restart is required before these settings are active.
Figure 1. Java Control Panel showing Java disabled in the browser
Multiple browsers installed on the same system can increase security by designating one browser to have Java enabled while the others are used as general-purpose browsers with Java disabled. The Java-enabled browser should only be used for sites that require Java, such as internal corporate applications, and be restricted from external browsing.
Segmenting a user's workstation from their browsing habits through the use of a virtual workstation can also add a layer of protection. The idea is that if the virtual machine (VM) becomes compromised, the malicious software will be contained within and will not have direct access to any data that may be on the physical machine. Reverting back to an older, non-compromised version of the VM is then easier using virtualization software. Virtualization products are available for OSX, Windows, and Linux, and are typically fee-based such as VMware Workstation, VMWare Fusion, or Parallels. There are also free ones available, such as VMware Player and Oracle's VirtualBox.
Another security feature that appeared in the Java control panel for version 1.7_10 is a Security Level setting for unsigned applets . The original default was Medium, but starting with version 1.7_11, the new default setting is High, which prompts the user before running any unsigned applet. While the High setting gives the user a chance to intervene before an applet is started, social engineering tactics can still persuade the user to click Run. The next level up is Very High and will not permit any unsigned applet to run. The Very High setting may be a good option for the corporate environment because many internal and product applets are typically signed.
Figure 2. Dialog generated by JVM to prompt the user before launching an unsigned applet
Figure 3. Dialog generated by JVM prompting the user to allow a self-signed applet to launch
By default, self-signed and invalid certificates will cause Java to prompt users before launching these full-access applets. Users are also prompted for applets with valid certificates if the check box on the Advanced tab of the Java Control Panel, under Secure Execution Environment called "Show site certificate from server even if it is valid" is checked. This option will cause Java to show the certificate information and allow the user to decide whether to run the applet or not.
Figure 4. Advanced tab in the Java Control Panel
Java version 7u25 allows the user to check the certificate to ensure it has not been revoked. Both Certificate Revoation Lists (CRL) and online Certificate Status Protocol (OCSP) may be used. These settings can be tuned under the Java Control Panel. In addition, version 7u25 has a More Information link used for pop-ups to allow the user to get more information about the dialog box.
Each browser has its own method of managing add-ons, but the simplest way to determine the version and test your browser's Java interaction is to use Oracle's unsigned Java applet, which will display your installed version and tell you if it is current. Browsing to Oracle's unsigned Java applet and clicking on the Verify Java version button, the site will attempt to load a Java applet and display the version of Java used to load it.
Mozilla/4.0 (Windows 7 6.1) Java/1.7.0_15
The above clearly shows the version of Java making the request and the operating system it is installed on.
Before updating, be sure to close all browsers to ensure that the latest Java environment will be used. Oracle recommends removing prior versions of Java when manually installing newer versions . Automatic updates can be configured to notify the user there is a new version available and to automatically install it, which will replace previous versions . However, at the time of this publication, Java 1.7_17 does not support Automatic Updates for the 64-bit version .
Modern firewall products can provide context-aware filtering that can add extra security against Java-based exploits. An example includes Cisco ScanSafe , which can scan Java applets using various data sources and protect against known and new Java-based attacks. Cisco IronPort  products can also be used to enable network administrators the ability to block Java MIME types, which can protect internal users that could be using insecure Java applets.
Java's support for multiple operating systems, browsers, and hardware has made it a significant target for attacks. Fortunately, beginning with Java version 1.7_11, Oracle has made changes to prevent automatically running unsigned applets. There also exist several other possible mitigations which can be used to protect against attacks.
Gregg Conklin (email@example.com)
The RedMonk Programming Language Rankings: September 2012
TIOBE Programming Community Index for March 2013
How do I disable Java in my web browser?
Setting the Security Level of the Java Client
Why should I uninstall older versions of Java from my system?
What is Java Auto Update? How do I change notify settings?
Cisco Cloud Web Security
Cisco IronPort AsyncOS 7.5 for Web User Guide
6492837: 64bit: Auto-update
This document is part of Cisco Security Intelligence Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.