Ok, I think that we've all got pieces of this puzzle and it's a doozy.
We can solve this, by our heads & ideas together.
I've got some thread isolation code that anticipates the StackOverflowError.
Michal's got the idea of using a reflective proxy in an annotation
Object for verification authentication.
So how about this:
Alter or extend MarshalledOutputStream to append the verification
reflective proxy after the String, in the writeAnnotation method.
Then we can use any existing URL scheme, remain compatible with earlier
versions and verify and authenticate the other end and ensure privacy
constraints have been met etc.
Then if the other end authenticates, we trust it.
This can be all isolated on a Unmarshalling Thread in a Single Thread
ExecutorService, where any StackOverflowExceptions are handled and
wrapped as IOExceptions for the client thread and no foreign code runs
or can be downloaded, until we authenticate and grant it.
Cheers,
Peter.
Michal Kleczek wrote:
On Tuesday 12 of October 2010 15:39:52 Michal Kleczek wrote:
On Tuesday 12 of October 2010 15:07:07 Sim IJskes - QCG wrote:
I dont like the idea, that we allow full deserialization before we have
had a change to let the IntegrityVerifier have a look at it.
But suppressing recursive readAnnotation already does that!!!
Doesn't it?
Even without this we do not run untrusted code.
What can happen is attacker can send u a corrupted stream that contains of
Modules annotated with Modules - but no untrusted code will have a chance to
run.
In the end you're going to get StackOverflowError and quit.
Michal
