river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: The internet - Proxy Isolation - Denial of Service Attack.
Date Wed, 09 Feb 2011 11:45:59 GMT
Greg Trasuk wrote:
> On Tue, 2011-02-08 at 10:49, Gregg Wonderly wrote:
>   
>> On 2/7/2011 8:44 PM, trasukg@trasuk.com wrote:
>>     
>>> Seems like this behavior ('isolate proxy') would be something you could specify
as an invocation constraint when you prepare the registrar proxy.
>>>       
>> I think that they are focused specifically on the fact that the registrar is 
>> already unmarshalling the proxy before you see it to do proxy preparation.  So, 
>> anything it does in the no-args constructor is a point of exposure to DOS attacks.
>>
>>     
>
> Right, but the registrar itself is represented by a proxy (i.e.
> LookupDiscoveryManager has a 'registrarPreparer' configuration item). 
> Since this behaviour ('isolate service proxy') is orthogonal to the
> lookup method's core functionality, doesn't it make sense to put an
> invocation constraint on the _registrar_ proxy, the same as we might put
> a 'make sure communication with the registrar is confidential'
> constraint?
>
> Cheers,
>
> Greg.
>   

Interesting, I hadn't considered a constraint. It would also be possible 
to isolate the registrar's proxy as well, that would be a discovery 
constraint however.

For a registrar proxy during discovery, the time that we need to protect 
against attack (if we're going to prepare and verify a proxy) is the 
unmarshalling period, when foreign code executes, but for the registrar 
proxy and discovery, the reference to the proxy and the verification 
process is relatively safe as no foreign code is executed.  Which is why 
the discovery denial of service that I posted earlier only protects the 
client during the period where the InputStream is read (Discovery V2 
Protocol) and the registrar's proxy unmarshalled, the returned registrar 
proxy is not wrapped.

It would also be possible to encapsulate the registrar proxy in 
isolation, but I haven't chosen to do this at this stage.

How important is multi threading to proxy's?

With the constraint approach we have to trust the registrar enough for 
it to do this for us, we would have to take the registrar at it's word, 
unless the platform does it for us.  It is possible to add this 
functionality to MarshalledInstance (part of the platform). We might 
allow the client to set configuration, however that's an all or nothing 
approach, it doesn't allow the client a different choice between 
different lookup services.

We could make it a privilege, a permission that if granted to the 
registrar proxy allows it to unmarshall looked up proxy's without 
protection.

But that doesn't feel right either, although it does allow the client to 
authenticate the lookup service before deciding to grant permission.  
When permission isn't granted, it could simply fall back to the safe 
option, without throwing a security exception.

Thoughts?

Peter.


Mime
View raw message