river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gregg...@gmail.com>
Subject Re: The internet - Proxy Isolation - Denial of Service Attack.
Date Tue, 08 Feb 2011 15:49:24 GMT
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.

Gregg Wonderly

> 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