On 2/7/2011 8:44 PM, tras...@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<j...@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<j...@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.
