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 _______ < pwned > ------- \ ^__^ \ (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>&1 | grep "does not support" > /dev/null; then ... On 32-bit systems, this causes java to print the help message. -- Jakub Wilk
Current thread:
- OpenJDK: java(1): untrusted search path Jakub Wilk (Jun 13)
- Re: OpenJDK: java(1): untrusted search path Stiepan (Jun 13)