In my understanding, the author deliberately wants to show the absolute paths when there are multiple jar files with the same name (Ex: a jar hell). Maybe we can add some more detail in the java.security so an admin knows what exact impact it has.
--Max > On Sep 8, 2018, at 3:41 AM, Sean Mullan <sean.mul...@oracle.com> wrote: > > 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
