oss-sec mailing list archives

Re: OpenJDK: java(1): untrusted search path


From: Stiepan <stie@itk.swiss>
Date: Tue, 13 Jun 2017 16:48:04 -0400

Hi, confirmed on Ubuntu 32-bit running OpenJDK 1.8.0_131 (modified slightly your exploit to use "echo pwned" instead of 
using cowsay pwned).

Stiepan

-------- Original Message --------
Subject: [oss-security] OpenJDK: java(1): untrusted search path
Local Time: June 13, 2017 3:23 PM
UTC Time: June 13, 2017 3:23 PM
From: jwilk () jwilk net
To: oss-security () lists openwall com

Running "java -help" can load code from a subdirectory of cwd:

$ javac launcher_en.java
$ mkdir -p sun/launcher/resources/
$ mv launcher_en.class sun/launcher/resources/
$ java -help
_______
&lt; pwned &gt;
-------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||

This happens because:

* By default (i.e. when CLASSPATH env var was unset and neither -cp nor -jar
was specified), java sets "." as the user class path:
https://docs.oracle.com/javase/8/docs/technotes/tools/findingclasses.html#userclass

* The help message is apparently supposed to be internationalized.

* The Java"s localization machinery loads classes:
https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html

On Debian systems, jarwrapper (a binfmt-misc thing for running executable jar
files) is affected. It contains the following code:

if java -d32 2&gt;&amp;1 | grep "does not support" &gt; /dev/null; then
...

On 32-bit systems, this causes java to print the help message.

--
Jakub Wilk

Current thread: