river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <michal.klec...@xpro.biz>
Subject Re: Towards Internet Jini Services (trust)
Date Mon, 04 Oct 2010 13:55:55 GMT
On Monday 04 of October 2010 15:39:44 Sim IJskes - QCG wrote:
> On 10/04/2010 03:28 PM, Michal Kleczek wrote:
> > The service can upload it's code to any code server available (it does
> > not have to be trusted). It can upload it's proxy to any untrusted
> > ServiceRegistrar or JavaSpace available.
> > Yet still - the client can make sure it is talking to the right service
> > via the right proxy.
> > The only hole is that a DOS attack during proxy deserialization can be
> > issued by a malicious service registrar. The question is - can this
> > problem be solved?
> I'm not sure, thats the only attack vector. The problem is already
> present in the lower layer: JERI.
> To me a service registrar is nothing more than a lookup table,
> associating service attributes with service UUID, and service UUID with
> ServerEndpoint+Object UUID. When you have selected the service, your
> classloader still has to download the code, but thats the responsibility
> of classloader and codeserver, who are verifying the trust relation.

It does not matter how the client got the proxy (be it from a 
ServiceRegistrar, an email message or a JavaSpace).

You use a Security.verifyObjectTrust() to check if the proxy is the right one. 
This in turn establishes a secure channel with the service (which _must_ 
authenticate to the client in a secure setup) to retrieve a verifier.

The problem is - you have to first deserialize the proxy. During 
deserialization or downloaded class initialization and then when retrieving 
ProxyTrustIterator the only thing that can happen ( if JVM security does not 
have holes ) is DoS since the code does not yet have any permissions.


View raw message