Contents
Overview
What is Java?
Java Applications vs. Java Applets in the Browser vs. JavaScript
Risks
Mitigations
Disable Java in the Browser
Use a Separate Browser for Java-based Web Applications
Use Virtualization
Enable Click-to-play or Other "Run on Demand" Features
Stay Updated
How to Determine Installed Version
How to Update
Use Context-aware Firewall Products
Summary
Acknowledgments
References
Overview
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.
What is Java?
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[1] and TIOBE Software[2] language trackers.
Java source code is compiled into Java bytecode (typically a .jar file), which is executed by the Java virtual machine (JVM). The JVM has been ported to many hardware and software platforms and is available to browsers as a plug-in. For reference, the Java Runtime Environment (JRE) is a combination of Java APIs and the JVM. For more information, see http://www.java.com/en/about/.
Java Applications vs. Java Applets in the Browser vs. JavaScript
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.
Java applications and Java applets run under the same powerful JVM; however, Java applets are generally untrusted, come from unknown sources, and are launched automatically by the browser when directed by a website. These applets are run inside of a protective layer called a sandbox. The sandbox restricts the applets from performing many dangerous activities, such as file system or network access, or the ability to execute applications. Java applets can also be signed, which elevates the trust level of the applet, and allows it to become equivalent to an ordinary application with full access to everything the user has access to.
Signed applets come in two types:
- Signed with a certificate created by a certificate authority (CA), which can be verified by the browser using the CA's certificate
- Self-signed with a certificate created by the developer, and thus cannot be verified by the browser
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.
Applets that have been self-signed by the developer are difficult for the user to verify the origin of and determine if they should be trusted. Thus, when trying to run such an applet from the browser, the user is warned that it will run unrestricted and could put personal information at risk, forcing the user accept the risk before running the applet.
JavaScript is sometimes confused with Java, even though it is a completely different technology. JavaScript is a scripting language that runs within the browser and can interact with the elements on the web page that delivered it. Unlike Java, JavaScript never had the dangerous functionality of file system access or process launching built into the language. However, JavaScript does typically play an important role with drive-by malware delivery because it is frequently leveraged to obfuscate the loading of malicious Java jar files, PDF, flash, or other components with flaws that are automatically loaded by a browser.
Risks
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.
Common threats delivered by Java exploits include downloaders that are capable of retrieving and executing other malicious software, as well as information stealers that gather things like banking credentials and intellectual property. According to the 2013 Cisco Annual Security report, Java exploits accounted for 87% of total web exploits.
An applet signed with a CA's certificate comes with its own set of risks. Since the CA certificates are built-in for the browser to automatically trust, and allow these types of applications to run with full control, you are trusting that the CA has not been compromised, or that fraudulent certificates have not been generated.
Mitigations
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.
The following is a collection of different ways to mitigate Java-in-the-browser risks.
Disable Java in the Browser
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[3]. Note that a browser restart is required before these settings are active.
Figure 1. Java Control Panel showing Java disabled in the browser
Use a Separate Browser for Java-based Web Applications
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.
Use Virtualization
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.
Enable Click-to-play or Other "Run on Demand" Features
Another security feature that appeared in the Java control panel for version 1.7_10 is a Security Level setting for unsigned applets [4]. 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[3], 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.
Stay Updated
How to Determine Installed Version
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.
For corporate installations where egress traffic can be monitored, the active Java install base can be determined by watching the User-Agent headers at network choke points, such as a proxy, firewall, or router. By monitoring web requests and extracting the User-Agent header information, you can get a view into the Java versions currently in use on the network. A typical User-Agent string would look like:
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.
Each browser has its own way of managing plugins, and the following list shows how to access the installed plugins from some popular modern browsers.
- Chrome: In the address bar, type chrome://plugins/ to see the list of plugins and their versions.
- Firefox: Click the Firefox drop-down menu and then select Add-ons. This will show you a list of the add-ons the browser currently knows about and their versions. Additionally, Mozilla also provides a plugin-check from their website to help identify many different outdated plugins, and is not limited to just Java.
https://www.mozilla.org/en-US/plugincheck/ - Internet Explorer 9: Go into Tools, and then Manage add-ons. From the Manage add-ons dialog, you may have to Show All add-ons and then click on the Java entries to see their details.
- Safari: From the Help option in the menu-bar, choose Installed Plugins.
How to Update
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 [5]. 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 [6]. However, at the time of this publication, Java 1.7_17 does not support Automatic Updates for the 64-bit version [9].
To start the manual update process, just direct your browser to http://java.com/getjava
Use Context-aware Firewall Products
Modern firewall products can provide context-aware filtering that can add extra security against Java-based exploits. An example includes Cisco ScanSafe [7], which can scan Java applets using various data sources and protect against known and new Java-based attacks. Cisco IronPort [8] 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.
Summary
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.
Training is still an important aspect to any security measure, as these new roadblocks can be overcome with the right enticement to the end-user.
Acknowledgments
Gregg Conklin (grconkli@cisco.com)
Software Engineer
References
The RedMonk Programming Language Rankings: September 2012
[1] http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12/
TIOBE Programming Community Index for March 2013
[2] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
How do I disable Java in my web browser?
[3] http://www.java.com/en/download/help/disable_browser.xml
Setting the Security Level of the Java Client
[4] http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html
Why should I uninstall older versions of Java from my system?
[5] http://www.java.com/en/download/faq/remove_olderversions.xml
What is Java Auto Update? How do I change notify settings?
[6] http://www.java.com/en/download/help/java_update.xml
Cisco Cloud Web Security
[7] //www.cisco.com/web/products/security/cloud_web/index.html
Cisco IronPort AsyncOS 7.5 for Web User Guide
[8] //www.cisco.com/en/US/docs/security/wsa/wsa7.5/user_guide/WSA_7.5.0_UserGuide.pdf
6492837: 64bit: Auto-update
[9] http://bugs.sun.com/view_bug.do?bug_id=6492837
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
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 in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.