river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Thu, 27 Feb 2014 01:53:13 GMT
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.



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"<jini@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

View raw message