On 8/29/18 10:01 AM, Baesken, Matthias wrote:
Hi Max, thanks for your input .
I created another webrev , this contains now the suggested
SecurityProperties class :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/
java/util/jar/Attributes.java
469 return AccessController.doPrivileged(new
PrivilegedAction<String>() {
470 public String run() {
471 return file.getAbsolutePath() + ":" + lineNumber;
472 }
473 });
I have a serious concern with the code above.
With this change, untrusted code running under a SecurityManager could
potentially create a JarFile on a non-absolute path ex: "foo.jar", and
(somehow) cause an IOException to be thrown which would then reveal the
absolute path of where the jar was located, and thus could reveal
sensitive details about the system (ex: the user's home directory). It
could still be hard to exploit, since it would have to be a known jar
that exists, and you would then need to cause an IOException to be
thrown, but it's still theoretically possible.
In short, this is a more general issue in that it may allow untrusted
code to access something it couldn't have previously. new
JarFile("foo.jar").getName() returns "foo.jar", and not the absolute path.
Granted this can only be done if the security property is enabled, but I
believe this is not something administrators should have to know about
their environment and account for when enabling this property.
The above code should be changed to return only what the caller provides
to JarFile, which is the name of the file (without the full path).
--Sean
