The annotation must be deserialized, serialization itself is insecure, we need to authenticate using a secure connection, prior to deserializing that annotation.
An attacker can use a serialization attack, without requiring jini, to create a ClassLoader and start downloading classes out of band. All the attacker needs is privileged context (how many people grant AllPermission to their own code), then the attack works. It can be avoided by using the principal of least privilege, provided there are no vulnerable jvm classes, but I don't know anyone who actually practises least privilege principles. Peter. ----- Original message ----- > Hmm... I am not sure I understand the concerns. > It is true you need to deserialize an annotation. But the classes to do > it must be either local or the annotation is annotated itself with > another annotation which in turn is going to be verified before used. > You verify them recursively so no untrusted code is executed to > deserialize any object. > To prevent DoS you can simply put limits on the depth of recursion. > > Michal > > On 2013-05-01 14:07, Peter wrote: > > You are a creative thinker, which is an important factor in finding the > > right > > solution. Creating those object annotations still requires > > deserialization > > and unfortunately serialization is just as insecure as unmarshalling if > > performed in privileged context; an attacker can escape the sandbox, it's > > also > > easy to cause dos by sending large amounts of data. > > > > We need to authenticate over a TLS sockets or some other secure form of > > communication, before transferring anything. > > > > After authentication using a secure connection we can establish enough trust > > to begin deserialization and unmarshalling. > > > > Currently secure discovery does this, but only for a lookup service, we need > > to work out how to extend that to any service. > > > > Cheers, > > > > Peter. > > > > ----- Original message ----- > > > Maybe it is the right moment to remind you of my idea that codebase > > > annotations could be objects treated exactly the same as service proxies > > > and verified with TrustVerifiers. Wouldn't it solve the problem? > > > > > > Michal > > > > > > On 2013-05-01 11:42, Peter Firmstone wrote: > > > > Hmm, yes we actually need to completely avoid Serialization and RMI > > > > until we've authenticated the remote end, I've been thinking about > > > > developing a ServiceLocator, that can be constructed from a string, > > > > that isn't serializable, but allows a service connection to be > > > > authenticated, prior to downloading a service proxy. > > > > > > > > A lookup service could return ServiceLocator's instead of Proxy's. > > > > > > > > On 1/05/2013 5:52 AM, Gregg Wonderly wrote: > > > > > It's interesting, that after all of these years of remote codebase > > > > > loading and all the associated security risks being openly discussed > > > > > and Sun's Jini team trying to address those, with no support for the > > > > > larger community (JSRs voted down), that this statement appears at > > > > > the end of the announcement. > > > > > > > > > > "Caution: Running a system with the java.rmi.server.useCodebaseOnly > > > > > property set to false is not recommended, as it may allow the loading > > > > > and execution of untrusted code." > > > > > > > > > > Really? How could that be a problem? And is it really something that > > > > > is only being realized now? > > > > > > > > > > Gregg Wonderly > > > > > > > > > > On Apr 30, 2013, at 6:53 AM, Dennis Reedy<dennis.re...@gmail.com> > > > > > wrote: > > > > > > > > > > > FYI, this caused grief yesterday on my project. Some of the team had > > > > > > updated Java to JDK 7 Update 21. With this update the following > > > > > > change has been made: > > > > > > > > > > > > The RMI property java.rmi.server.useCodebaseOnly is set to true by > > > > > > default. In earlier releases, the default value was false. > > > > > > > > > > > > More detail here: > > > > > > http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html > > > > > > > > > > > > The simple fix for us is to set > > > > > > -Djava.rmi.server.useCodebaseOnly=false > > > > > > > > > > > > HTH > > > > > > > > > > > > Dennis > > > > > > -- > > > Michał Kłeczek > > > XPro Quality Matters > > > http://www.xpro.biz > > > > > > > > -- > Michał Kłeczek > XPro Quality Matters > http://www.xpro.biz >
