Re: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation

Ron,

I get the feeling we are talking at cross-purposes here.  There is a way 
in which the JMX Remote API can be used by malicious code to gain 
privilege if it does not make the checks that the RI makes.  This could 
be code that you didn't even know was going to use that API.  All you 
know is that you assumed that if you granted an applet (say) the ability 
to open a server socket on port 2000 then it would be able to open a 
server socket on port 2000, but it would not be able to delete files, 
even if a principal "superuser" in your system does have the ability to 
delete files.  But, in fact the code takes advantage of its permission 
to create a JMXConnectorServer in such a way that any connection to that 
server gets authenticated as "superuser".  The applet, or anyone else, 
connects to the JMXConnectorServer and accesses the DeleteFilesMBean. If 
you don't consult the permissions of the entity that created the 
connector server, then you will execute all MBean operations as 
"superuser" and bang, your applet can delete files.

-- 
Éamonn

Ron Vered wrote:
> Eamonn,
> 
> Thank you for all your comments!
> 
> Ron.
> 
> Reply-To: mx4j-devel
> 
> Ron Vered wrote:
>  > Éamonn McManus wrote:
> 
>>>If this Subject's permissions were not
>>>intersected with the creator of the connector server (1), then 1 
>>>could create an RMIConnectorServer with a JMXAuthenticator that 
>>>always returns a 3 that is a highly-privileged Subject.  1 could then 
>>>connect to itself and execute code with the permissions of 3
> 
> 
>>So what is the alternative? Make (1) have AllPermissions (or something 
>>close to it)? So you get same result. In fact, I think its not same 
>>result, it is has the great disadvantage that this (1) is pretty much 
>>constantly running at high privilege. With RMI and object 
>>serialization, it can potentially load some malicious code from a 
>>client and run it in high privilege. If run in low privilege, then 
>>even if you forgot some hole, malicious code will have hard time doing 
>>anything useful.
> 
> 
> Yes, (1) does need to have a strong set of permissions.  I do not see a 
> security problem with serialization, or with code downloading which is 
> probably what you are thinking of.  Even if an evil client does manage 
> to download code into the server, that code will have no permissions 
> because, unlike the code that created the RMI connector server, its 
> codebase will not be mentioned in the java.policy file.
> [Ron] maybe not, it may be principal based permission (which is what I am discussing)
> The fact of the matter is you are unnecessarily running in high privilege which opens the door
> To all sort of exploits which will not be possible at low privilege.
> 
> There is little point in making it possible for the connector server to 
> have low privilege if it is done in such a way as to allow it to amplify 
> that privilege at will.
> [Ron] the Subject can be explicitly trusted to do this, which will achieve overall better security
> Because things have exactly the permissions they need, instead of artaficially adding permissions.
> Like the guard to the oval office (see below).
> Please change the phrase 'at will' to 'as trusted to do'.
> 
> Then malicious code *will* be able to do useful 
> things.
> [Ron] (didn't you just said will not because of different code base?) It will have to go through a two step process to do this: compromise the server in a specific way so as to capture control at a later time, then sit and wait for high privileged user to come along.
> In current design, you need only to compromise the server, since it already has permission.
> 
> 
>>Then there is the problem of initialization. If the server is a daemon 
>>(and needs high privileges) the problem of where to store its 
>>credentials becomes more difficult because the extra care required.
> 
> 
> In other words, you need to set up your java.policy carefully, yes.
> [Ron] not enough, you need to store a sensitive secret somewhere. With unnecessary high privilege, getting this secret can be a one step process for a malicious client.
> 
> 
>>I think that although (1) may have low privileges, it still can be 
>>trusted in someway. To use the president allegory, the guards to the 
>>oval office don't have the privilege to launch ICBMs, but the do 
>>control if the president is allowed in or not to push the button.
> 
> 
> Interesting allegory.  A corrupt guard can let in someone who is not the 
> president, and that someone can then push the button.  So if you don't 
> trust the guard not to push the button then you can't trust him to 
> decide who does.  This translates exactly to the case at hand.
> [Ron] That's right! Guard does NOT have permission to push the button!
> He only facilitates the transport of the president to do it. He is trusted in a limited way.
> It would not make sense to give the guard the permission to push the button only so the president could do it. In fact, the world would be much less secure if the guard had permission to do it, and thankfully, there is no artificial need to give the guard this privilege!
> 
> 
>>>Note that the authenticated subject from a connection does not need 
>>>to have any permissions other than SubjectDelegatePermission and 
>>>possibly some JMX permissions.  It doesn't need to have 
>>>FilePermission or whatever, provided that remotely-invoked operations 
>>>that need those permissions do them through a delegated Subject.
> 
> 
>>[Ron] I want to clarify this point (so we did not make an incorrect
>>conclusion): If the "authenticated subject from a connection", which I 
>>refer to as (2), does not have say FilePermission AND the delegate 
>>Subject (3) does have it, and then the code goes ahead and does a file 
>>operation through some MBean, before this fix, will it fail or 
>>succeed? I think it will fail because (2) does not have this 
>>permission, but correct me if I am wrong. This is, in fact the aspect 
>>MORE CRITICAL to us in fact, we don't care that much if (1) will have 
>>high privileges.
> 
> 
> I cannot speak for MX4J, but with the Reference Implementation, (2) does 
> not need to have FilePermission.  (1) and (3) do.
> [Ron] Let me check this again.
> 
> Regards,


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&op=click