On 1/8/19 7:17 PM, Philipp Kunz wrote:
Manifest.read throws an exception with the jar file name passed to the
constructor the manifest was constructed with and not passed to the call
to the read that throws the exception because the jarFilename variable
is not reset after successful construction with read and will be used by
subsequent calls to read if read is called (again) after the manifest
has been constructed. The call to the constructor could be in a
different context than the call to read and the jar file name could
therefore be exposed in an unexpected context. After I first thought it
was just annoying to get an unrelated jar file name in an exception
message I see now a security concern as well.
That's a good point (and good catch!). I think we need to adjust the
code so that if read is called and it throws an Exception it only
contains the jar file name if called by the constructors in which the
jar file name is passed as a parameter. Perhaps break up the read method
into a private and public one with the private one containing an
additional boolean parameter that is set to true if called by the
constructor, otherwise it is false. If the boolean parameter is true,
the jar file name is put in the exception, otherwise it is not.
I also think we should fix this in 12, so I raised the priority to 3.
--Sean
At first glance and in terms of expectable code changes to the
questionable constructor of Manifest the above mentioned seems to be
overlapping with issue JDK-8216362 but then JDK-8216362 is about the jar
file name missing in an error message when it should be present and not
the other way round. Attached is a patch for JDK-8216362 as it is
described at the moment.
Philipp
On Tue, 2019-01-08 at 13:07 -0500, Sean Mullan wrote:
In this case, the caller is passing in the filename through the public
JarFile API so as long as it is not modified it should be ok. The
concerns I raised previously are situations where the caller did not
pass in the file or the JDK converts a relative path to an absolute
path, which could reveal sensitive details about the filesystem.
--Sean