The SSL endpoint provides you the ability to do authentication up front. That's the path that I've always considered for how one would lock down (de)serialization attacks. The "DownloadPermission" is also a part of the controls which try to make things more secure. But, because it's "off" by default, so that downloading code works, it's often overlooked. If you could get everything into everyone's classpath, as a Maven artifact or otherwise, then the "no downloaded code" mantra, could be a successful path to service and client deployment in a more public arena.
There are lots of things that we can try/change/do. Ultimately, a non-serialization based transport of some pieces of data which are verifiable with signatures, is the entry point we should aim toward. Whether that just means us SSL endpoints or some other endpoint that keeps serialization out of the conversation is what is in question. We've not talked about other data formats such as JSON in some time. A string of bytes encoded as JSON might be viable for many reasons, and there is always the rest of the story where we could just create a web server endpoint that uses JSON and then we'd have integration with the world. I do use some pretty complex objects in many of my services, but certainly, in the end, they are JSON encodable because they are just strings and numbers and dates. Gregg Wonderly On May 1, 2013, at 7:07 AM, Peter <j...@zeus.net.au> 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 >> >
