Java Web Start is a technology for easy client-side deployment of Java applications. “Using Java Web Start technology, standalone Java software applications can be deployed with a single click over the network” (from Sun Microsystems’s website).
Java Web Start is installed with Java Runtime Environment (JRE). During installation, file type associations are added to make web browsers automatically (with a single click) open Java Web Start’s .JNLP files (the behavior may vary between different web browsers).
There is a vulnerability in the way Web Start handles Java system properties defined in JNLP files. A malicious user can pass command line arguments to the Java virtual machine. They can be used to disable the Java “sandbox” and compromise the system. The attack can be carried out when the victim user views a web page crafted by the attacker.
The <property> tag in a JNLP file can be used to define Java system properties. System properties are key-value pairs which usually store attributes of the current working environment, e.g. “java.home” containing the Java installation path and “java.version” containing its version. Due to the nature of some of the system properties, setting their values in JNLP files is restricted.
A few system properties are considered “secure” and if defined in a JNLP file, they are passed to the Java executable (javaw.exe) via the -Dproperty=value command line argument. However, a malicious user can use this feature to inject extra command line arguments to the Java executable.
For instance, a JNLP file can contain this property tag:
<property name="sun.java2d.noddraw" value="true HELLO" />
The property “sun.java2d.noddraw” is considered secure by Web Start, so it is accepted and the startup command for the application is something like this:
javaw.exe -Dsun.java2d.noddraw=true HELLO (other args) your.application
This would produce a Web Start error message saying the main class can’t be found, as javaw.exe interprets “HELLO” as the main class name instead of “your.application”. The problem is that Web Start fails to use quote symbols around the property argument.
To exploit the flaw, an attacker can pass command line arguments affecting the Java security policies. Normally an unsigned, untrusted Java application operates inside a “sandbox” and can’t e.g. access local files. By exploiting this flaw, the default “sandbox” security policy can be overridden with an arbitrary policy file hosted on the attacker’s web server. The new policy can grant full permissions to the application, which could then e.g. read or write arbitrary files on the victim system, or download and launch viruses, keyloggers or other malware. The attacker may set up a JNLP file on a web server so that it will be launched without further user interaction when the victim visits the site, e.g. with the IFRAME tag.
As the application is made in Java, the same exploit can work on any platform supporting Java Web Start. A proof-of-concept exploit was produced which detects the operating system and starts an OS-dependant binary executable when a web page is visited – the same exploit works with Internet Explorer on Windows and Mozilla Firefox and Opera on Linux.
If Internet Explorer is used, the JNLP file is opened automatically without further interaction. Other web browsers may, depending on file type configuration, display a dialogue asking whether the file should be opened or saved. Some versions of e.g. Opera require manual configuration in order to open JNLP files.
In addition to the web browser attack vector, the attacker could replace an existing JNLP file on a web site with a malicious one. Web Start applications can be started from desktop shortcut icons, from the Web Start menu, or from command line. All of these starting methods are suspectible to the attack.
Java Web Start in J2SE 1.4.2 releases prior 1.4.2_07 are vulnerable. J2SE 5.0 and later, and releases prior to 1.4.2 are NOT vulnerable.
Sun Microsystems was informed about the problem on September 25, 2004. The issue was fixed in J2SE 1.4.2_07. Sun’s advisory can be found at
The advisory also contains workarounds for the problem.
The vulnerability was found and researched by Jouko Pynnönen (email@example.com), Finland.