[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RE: RFR: JDK-8068155: [Findbugs]new sun.jvm.hotspot.utilities.ObjectReader() creates a
From:       Sharath Ballal <sharath.ballal () oracle ! com>
Date:       2016-09-16 8:47:24
Message-ID: 7d5acf26-3db2-4bab-a3c5-3f187b1fd40c () default
[Download RAW message or body]

I tried to do some experiments from my side to check if this issue could be hit, but \
I could not successfully do anything.  As per the discussion in this thread, I will \
close the bug as 'not an issue'.  Thanks all for the inputs.


-Sharath Ballal


-----Original Message-----
From: Dmitry Samersoff 
Sent: Thursday, September 15, 2016 4:19 PM
To: Harsha wardhana B; Sharath Ballal; David Holmes; \
                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

Sharath,

I don't see any requirements that ObjectReader should run with an application that \
install security manager but doesn't have RuntimePermission.createClassLoader

So I would recommend to close this bug as "not an issue".

-Dmitry

On 2016-09-15 06:38, Harsha wardhana B wrote:
> 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
> > > 
> > > 
> > > 
> > > 
> > > 
> 


--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


[prev in list] [next in list] [prev in thread] [next in thread]