Saturday 24 September 2011

JNLP Application Security Assessment – Part 1 : Analysis of the JNLP file

Hello All,

Time for part 1 of our series.

During this part I will analyse all the sections of a typical .jnlp file. I understand that this may seem a bit of an overkill for a "JNLP Application Security Assessment" series of posts but it will provide a background to any reader that is not familiar with the structure and architecture of jnlp and Java WebStart.

Below is an brief description of what Java WebStart and jnlp is from Oracle.
The Java Network Launch Protocol (JNLP) enables an application to be launched on a client desktop by using resources that are hosted on a remote web server. Java Plug-in software and Java Web Start software are considered JNLP clients because they can launch remotely hosted applets and applications on a client desktop.

The main component of Java Web Start is the .jnlp file. It is an XML based file that

  1. instructs the java web start to take over the execution of the application,

  2. loads or downloads each required jar file - depending on whether it is the first time that the jnlp software is executed or not and the response from the web server when each jar file is requested (HTTP/1.1 304 Not Modified vs other)

  3. starts the java vm with the required execution parameters

  4. starts the java application with the required parameters & properties.

There are several explanations in the net regarding the structure of the jnlp file. The two best I have found are

The image below is itself taken from the Specification archive and is in my opinion a very precise and condensed presentation of the jnlp XML file structure

jnlp file overview

From the above elements the ones that are more significant from a security testing perspective are the following:

  1. security: It defines all runtime permissions that the jnlp application will have

  2. resources: All of its child elements are important

    1. j2se: defines the required runtime version as well as java vm options that need to be passed at runtime eg. max heap , debug , etc. They are defined in the java-vm-args directive inside the j2se child element.

    2. jar: defines all java archives that compose the application itself. Those are downloaded ad-hoc at first application execution or are checked for modifications by the runtime at each subsequent application execution

    3. property: defines all properties that need to passed to the application at runtime as well, those are passed via the to the java vm via the -Dpropertyname=value directive.

    4. package: defines which packages are implemented in which JAR files.

    5. nativelib:  defines a jar file that contains native libraries in it.

  3. application-desc: defines runtime parameters to the application The main are:

    1. The class that contains the main function

    2. arguments passed to the application

  4. application-desc: defines runtime parameters to the application The main are:

    1. The name of the main applet class

    2. params passed to the applet

Now that the foundations have been set, it is time to see a couple of real life examples that tie all of the above together.

[sourcecode language="xml"]
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for launching ArgoUML with WebStart -->
<title>ArgoUML Latest Stable Release 0.32.2</title>
<vendor> (Open Source)</vendor>
<homepage href=""/>
<description>ArgoUML application.
This is the latest stable release.
<description kind="short">ArgoUML 0.32.2</description>
<icon href="" width="16" height="16" />
<icon href="" width="32" height="32" />
<icon href="" width="64" height="64" />
<j2se version="1.5+" max-heap-size="512m"/>

<jar href=""/>
<jar href=""/>
... this application has a lot of jars ...
<jar href=""/>

<property name="argouml.modules"
value=";org.argouml.state2.StateDiagramModule;org.argouml.sequence2.SequenceDiagramModule;org.argouml.activity2.ActivityDiagramModule;org.argouml.core.propertypanels.module.XmlPropertyPanelsModule;org.argouml.transformer.TransformerModule;org.argouml.language.cpp.generator.ModuleCpp;org.argouml.language.cpp.notation.NotationModuleCpp;org.argouml.language.cpp.profile.ProfileModule;org.argouml.language.cpp.reveng.CppImport;org.argouml.language.cpp.ui.SettingsTabCpp;org.argouml.language.csharp.generator.GeneratorCSharp;;;;;;;;org.argouml.language.php.generator.ModulePHP4;org.argouml.language.php.generator.ModulePHP5;org.argouml.language.sql.SqlInit;org.argouml.uml.reveng.classfile.ClassfileImport;org.argouml.uml.reveng.idl.IDLFileImport"    />
<application-desc main-class="org.argouml.application.Main"/>

Following on our definition of interesting sections, we can see that the jnlp file has:

  1. all available security permissions to perform any actions on the users' workstation (Lines 20 - 22)

  2. It requires java 1.5 and greater to function as well as a maximum heap size of 512 MB (Line 24)

  3. It requires a lot of jars that will be downloaded and saved at the users' workstation (Lines 26 - 29)

  4. A single property is passed to it at runtime, argouml.modules (Line 31).

  5. Its main function is loaded from org.argouml.application.Main and a single parameter is passed to it (Line 34)

Another jnlp file with interesting parameters is the one below from the javaemvreader project:

[sourcecode language="xml"]
<!--?xml version="1.0" encoding="utf-8"?--><?xml version="1.0" encoding="utf-8"?>
<jnlp  spec="1.6+" codebase="" href="webstart.jnlp">
<title>Java EMV Reader</title>
<homepage href=""/>
<description>Java EMV Reader</description>
<j2se version="1.6+" java-vm-args="-esa -Xnoclassgc"/>
<property name="jnlp.versionEnabled" value="true"/>
<jar href="javaemvreader-latest-full.jar" main="true"/>
<application-desc main-class="sasc.Main"/>

The interesting bit here is the java-vm-args directive at the j2se section. Basically it is used to initiate the java virtual machine with the appropriate configuration settings and ensure a correct execution environment.

That is it for Part 1 of our tutorial. Part 2 will describe the behavior of a jnlp file execution, ways to interfere with is by manipulation some of its critical parameters and changing the execution model from Java WebStart to native java application.


No comments:

Post a Comment

Note: only a member of this blog may post a comment.