February 27, 2021
Hot Topics:

Basic Java Security, Part 1: Recent security developments for Java virtual machines

  • By Thomas Gutschmidt
  • Send Email »
  • More Articles »

"Sun, Netscape, and Microsoft all responded quickly and efficiently to these threats, and in fact, there are no known cases of exploitation from either of these flaws. This may be due to the civic responsiveness of individuals discovering them and the quick response of community organizations like CERT. "

Last month security flaws were found in both Internet Explorer and Netscape involving Java. Both flaws were similar, involved applets gaining access outside of the sandbox model of security, and were promptly acted upon when discovered.

Java as a platform utilizes several layers of security, one of which is the sandbox. Java's sandbox, in brief, works by limiting an applet's access. JDK 1.0 regulated applets to the file system in which they were launched (essentially confining it to the browser).

With JDK 1.1, programmers were able to bundle Java programs using digitally signed Java archive files, or JARs. This allowed programmers to write applets with full system access, which users could download. The user would have to give the applet permission to have full access by accepting the digital signature of the programmer. Untrusted applets, however, were still limited to the sandbox.

JDK 1.2 has a new security architecture that allows for an extensive and elaborate local security policy. End users can determine how much access any single applet has to any part of their machine or system by utilizing a number of new and powerful classes.

The key to the sandbox, however, is that an applet, unless with specific permission from an end user or administrator, should not have access to file systems outside of it's immediate vicinity. This means unsigned applets should have no ability to read any files outside of the sandbox.

There's a Bug in My Java

On August 10th CERT (Computer Emergency Response Team) released an advisory that Netscape's 4.x (4.04 through 4.74) browsers shipped with Java classes that allowed applets to access local and remote resources despite the sandbox. Applets did this by exploiting a hole in Netscape's Java Runtime Environment (JRE), opening a connection to a URL using the 'file' protocol. It was reported that an applet was able to open resources using other protocols as well. Once it was able to access local files, it could send them back to the applet's originating server. This vulnerability was titled "Brown Orifice" and was first demonstrated by Dan Brumleve on August 5th.

Sandboxed applets were able to do this by bypassing Securitymanager(). Normally, classes that could be considered security risks, such as FileInputStream() or Socket(), are forced to check with Java's SecurityManager before reading outside the sandbox. These classes would have to call the SecurityManager.checkRead() method to access a local file, or the SecurityManager.checkConnect() method to gain access over a network. Netscape's JRE classes netscape.net.URLInputStream and netscape.net.URLConnection ignored the checks with SecurityManager when passed a URL. This means that someone designing a malicious applet could read local files using URLs of the type "file://". The applet could also download files through "http://", "https://", or "ftp://", allowing attacks to read resources on a Web server, secured Web server, or FTP server, even if the applet was now behind a firewall.

These classes allowed an applet to run as a Web server within Netscape Navigator's JRE. The Web server applet could access any local file or networked file the user had access to via URLs and then send these files to the originating server. This would happen without any warning to the user — as long as Java was enabled on the Netscape browser. Netscape quickly patched a fix for Netscape Communicator 4.75 (and their beta 6 version), although this vulnerability still persists with earlier versions of Netscape for Windows, Macintosh, and Unix operating systems.

Microsoft has also recently updated their Java Virtual Machine (JVM) in response to security issues within the sandbox. The flaw affected JVM builds in the 2000, 3100, 3200, and 3300 series, which includes every build of I.E. 4.X and 5.X. The flaw allowed an unsigned applet to read and send information outside of the sandbox under certain parameters. The applet could then masquerade as the affected browser, browse within a network or past a firewall, go to secure sites if passwords were stored or cached, and send the information back to the server the applet originated from. This would effectively allow a hacker to browse sites as the user who downloaded their applet. They could also possibly achieve Telnet or FTP access.

The JVM allowed access through getSystemResource() and getSystemResourceAsStream(). The getSystemResource() function would accept the ../ string in the pathname, which meant it could verify (but not read) the existence of any file outside of the sandbox but within the same drive. Then getSystemResourceAsStream() could read specified files verified with getSystemResource() if it was within certain paths. It would have to be within the JVM home directory, which is the Desktop for IE 5.0, or C:\ for I.E. 4.0, or within the CLASSPATH environment variable.

Hideo Nakamura of NEC in Tokyo first reported the vulnerabilities to Microsoft, who promptly released a JVM patch that fixed the bug.

Up the Sandbox

Java's security system is extensive and well designed. Like all systems, it relies on a number of assumptions, one of which is a secure JVM. Sun, Netscape, and Microsoft all responded quickly and efficiently to these threats, and in fact, there are no known cases of exploitation from either of these flaws. This may be due to the civic responsiveness of individuals discovering them and the quick response of community organizations like CERT, SlashDot, and Bugtraq.

Once the library implementation of the sandbox is compromised, other Java security features, such as stringent memory management, language protocols for arrays or casts, and byte-code verification, become less significant. When one piece of the security system breaks down or is exploitable, the entire language becomes open for misuse. The only protection for now, it seems, is to keep as current with browser technology as possible. For more information on these threats and browser security, please reference the resources below.



    Tricks of the Java Programing Gurus. Vanderburg, Glenn. Sams.net Publishing, 1996.

See Also

About the Author

Thomas Gutschmidt is a freelance writer, in Bellevue, WA, who also works for Webvan Group Inc./HomeGrocer.com.

This article was originally published on September 21, 2000

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date