It was River-362.

You're assuming the Java sandbox is secure, history tells us otherwise. Your Module provider is quite interesting however and it could still serve a purpose for River, but it's outside the scope of River-362.

The proposed solution is to restrict deserialization to a list of classes that form a trusted computing base (only code audited as secure would be included), this then allows two things:

   * Ability of clients to limit deserialization to a trusted computing
     base while authentication and proxy verification is performed. (In
     java anything that implements Serializable can be serialized, so
     this is a small trusted subset of what is currently Serializable).
   * Additional benefit of allowing untrusted parties to interact
     securely using no code downloads, (java.lang.reflect.Proxy) based
     services, with a limited trusted computing base.

So it limits plain old Serialization as well, not just codebase downloads.

This solution would also work with your module provider.

Can I suggest creating a new Jira for your module provider, with an explanation of its capabilities and benefits?

Hope this helps explain it.

Cheers,

Peter.


On 26/02/2014 10:09 PM, Michał Kłeczek wrote:
Peter,

I think you dont remember the idea. It's been a long time.
It DOES prevent untrusted code from executing because a codebase annotation
is verified BEFORE it has a chance to load code.

Regards,
Michal
26 lut 2014 12:31 "Peter"<j...@zeus.net.au>  napisał(a):

----- Original message -----
This. I like this. How would this work, would it be an Entry, an
attribute of the service (perhaps similar to the ServiceUI factory?).
My PoC is attached to one of the issues in Jira (I'll try to find it
tomorrow once I have some more time). It was discussed some time ago on
this list mainly with Peter.
In our previous discussion, the aim was to determine a way to ensure that
no untrusted objects could be deserialised and thus prevent DOS attacks.

Because ProxyTrustVerifier checks are performed after deserialisation,
this wasn't a good solution for that specific problem.  That doesn't mean
to say it wouldn't be useful for other purposes.

The solution to avoid downloading untrusted objects, is to prevent
deserialisation of untrusted classes, by checking the serialization byte
stream and limiting deserialisation to a specific list of local classes
until after trust can be established.

I think this combined with Dennis' method of provisioning codebases and
secure endpoints would be a very difficult to crack security layer.

That doesn't mean that object based annotations cannot be used, making the
annotation field a String doesn't mean you can't deserialise any Object, it
just means that after an object other than String is deserialised, a
ClassCastException will be thrown, by that time an attacker may have
already created a ClassLoader, if deserialisation is performed in
privileged context.

Once we depreciate RMIClassLoader and replace it with RiverClassLoading,
then we could allow annotations to be objects.  After all, codebase
annotations are also part of the serialised stream, so we can secure them
by limiting them to a known trusted subset of classes as stated above.

Regards,

Peter.


Basically the idea is to change codebase annotation from
java.lang.String which needs to be interpreted by the client to an
object implementing an interface.
This object can be verified in exactly the same way as normal proxies
are verified ( by a TrustVerifier - in particular the ProxyTrustVerifier
). All that happens during deserialization.
It does not have anything to do with Entries since it is implemented at
the layer below that - hence is available for _all_ downoladed code (for
RemoteEventListeners as well :-) )

Regards,
Michal

--
Michał Kłeczek
XPro Quality Matters
http://www.xpro.biz



Reply via email to