Hello,
It is not required that SA should be run under security manager to
address this change. Any standalone application when run under security
manager can use ObjectReader class to exploit vulnerabilities. That is
something that should be evaluated.
With the below fix any application when run under security manager
without RuntimePermission.createClassLoader will be able to create
ProcImageClassLoader. We need to check if it is something that is
desired and what vulnerabilities can be exploited, if any.
-Harsha
On 9/14/2016 5:58 PM, Sharath Ballal wrote:
David,
That aside, the code uses raw types, which is bad. It should also be able to
retain the this(...) invocation e.g (I haven't compiled this):
This works, Thanks.
-Sharath Ballal
-----Original Message-----
From: David Holmes
Sent: Wednesday, September 14, 2016 3:07 PM
To: Sharath Ballal;serviceability-dev@openjdk.java.net
Subject: Re: RFR: JDK-8068155: [Findbugs]new
sun.jvm.hotspot.utilities.ObjectReader() creates a
sun.jvm.hotspot.utilities.ProcImageClassLoader classloader, which should be
performed within a doPrivileged block
Hi Sharath,
On 14/09/2016 6:14 PM, Sharath Ballal wrote:
Hello,
Please review this fix to add creation of classloader code into
doPrivileged block
Issue:https://bugs.openjdk.java.net/browse/JDK-8068155
Webrev:http://cr.openjdk.java.net/~sballal/8068155/webrev.00/
First I'm also curious about why FindBugs thinks this is needed. AFAIK you use
the doPrivileged to allow you to create the classLoader when it would otherwise
fail if a SecurityManager were present.
That aside, the code uses raw types, which is bad. It should also be able to
retain the this(...) invocation e.g (I haven't compiled this):
public ObjectReader() {
this(AccessController.doPrivileged(
new PrivilegedAction<ClassLoader>() {
public ClassLoader run() {
return new ProcImageClassLoader();
}
}
));
}
Thanks,
David
-Sharath Ballal
