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 > > > >
