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






Reply via email to