OK...
I don't know how severe this is. I don't think it is a huge problem but I think
that by default we should not allow methods defined within java.lang.Object to
be exported.
I was thinking you could do a DoS by calling wait() on the remote machine
multiple times. This can't happen because there is no monitor on the service's
object so you get an IllegalMonitorStateException.
You can get the object hashCode... I am not sure this gives you anything.
You could call clone() multiple times... If the deployed object is creating DB
connections that might cause some breakage.
You could also call finalize()...
You can't get a hold of java.lang.Class by the getClass method because there is
no serializer for this. This would by far be the easiest DoS.
Regardless. It probably would be good defensive programming to only export
functions which are defined in the service class and not in an parent classes.
An implementation would call Method.getDeclaringClass to make sure the method
can be safely exported.
Sound good?
Anyway... just thought of this...
Kevin
--
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/
In this business, the only real open industry standard in the computer industry
is Linux, which thankfully remains beyond the clutches of the moguls. Everything
else is hokum designed to lock developers (and by extension, customers) into
proprietary corners of the computing constellation.
