river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tras...@trasuk.com
Subject Re: The internet - Proxy Isolation - Denial of Service Attack.
Date Tue, 08 Feb 2011 02:44:45 GMT
Seems like this behavior ('isolate proxy') would be something you could specify as an invocation
constraint when you prepare the registrar proxy.

Greg

-----Original Message-----
From: Peter Firmstone <jini@zeus.net.au>
Date: Tue, 08 Feb 2011 09:27:09 
To: <river-dev@incubator.apache.org>
Reply-To: river-dev@incubator.apache.org
Subject: Re: The internet - Proxy Isolation - Denial of Service Attack.

Dan Creswell wrote:
> ....
>
> On 6 February 2011 06:31, Peter Firmstone <jini@zeus.net.au> wrote:
>
>   
>> I've refactored Proxy Isolation and added return value checks, to ensure
>> that remote code cannot be passed to the calling thread.
>>
>> It's basically just an invocation handler to be used for creating a
>> reflective proxy that can be used to pass method calls to a smart proxy,
>> isolated in it's own thread and ClassLoader.
>>
>> The caller communicates with the remote code using method invocation,
>> return values are checked to ensure remote code does not escape thread
>> isolation.
>>
>> The basic idea behind this class is:
>>
>> On the internet, you might find a service (with a smart proxy) your
>> interested in, but you don't know and cannot authenticate its subject.
>>  Since purely reflective proxy's on the internet will probably experience
>> some latency issues, it's more practical to allow execution of remote code
>> locally.
>>
>>
>>     
> Is that sufficient justification for this or should we be looking to spec
> things so that one can authenticate etc if it's important or otherwise just
> proceed as usual?
>
> Dunno, thinking out loud but my stock approach is to see about the specs
> before worrying about code...
>
>   

Your right, this is an implementation detail, so we don't want the 
client being exposed to it directly.  The most logical application would 
be by a registrar that provided proxy isolation, as an option in it's 
lookup call.

Which is why I've brought it up now, since we've been discussing the 
lookup service.

The registrar needs to know if the caller requires isolation, and if so 
be provided a timeout either by configuration or directly(which can be 
converted to a RemoteException and logged).

It's still possible for the client to authenticate the proxy and to 
perform proxy preparation and verification.

This form of isolation allows safe unmarshalling of the proxy prior to 
verification, although it would also be desireable to close any input or 
output streams relating to the proxy (I think I have a solution to this 
I'll discuss later).

This can't be part of the proxy verification process, since the proxy 
has been unmarshalled prior to proxy verification.

This needs to be abstracted from both the client and the service proxy.

Cheers,

Peter.



>   
>> By isolating the smart proxy within it's own thread and classloader, the
>> smart proxy has no permissions, other than those required to communicate
>> with it's originating server, it cannot cause a StackOverflowError, all it
>> can do is consume it's own thread, the calling thread can catch a
>> TimeoutException and continue.  I'm thinking of encapsulating any Exceptions
>> in a RemoteException, so existing clients can utilise it.
>>
>> This might leave a background daemon thread for some time if code is
>> malicious, eventually it will experience a stack overflow and be terminated
>> (if stuck in an endless loop) or be interrupted, but since these threads
>> have low priority, they can't do much harm, the number a box can withstand
>> and continue running, depends on how much memory it has, whether it's
>> running a 64 bit jvm and what the thread stack size is.
>>
>>
>> Cheers,
>>
>> Peter.
>>
>>
>>     
>
>   
Mime
View raw message