[RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

Sean Mullan sean.mullan at oracle.com
Fri Sep 7 19:41:10 UTC 2018

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/


  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).


More information about the core-libs-dev mailing list