river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: JDK 7 Enhancements just bit me again
Date Wed, 01 May 2013 15:57:31 GMT
Looks like we've gone into an interesting conversation again :) 

What I consider one of the biggest issues here is the need to download a service's codebase
every time. I can see downloading a codebase for a service once (or never-consider you can
have the -dl.jar locally installed), and then using the downloaded jars locally. Never create
a ClassLoader that loads jars (classes) from a remote location. This is the approach I took
with the artifact: based codebase. All jars are resolved and downloaded first, then loaded
as local resources. This happens once for a service version. Once downloaded, the coordinates
of the artifact are used to navigate to a locally installed classpath. Using http(s): based
codebases is very problematic and the cornerstone to the implied security concerns that follow.

Having certified repositories that require authentication allows you to establish trust before
anything is downloaded. The mysterious random downloadable codebase issue goes away, as does
the lost codebase issue. However, whats important is that there is an annotation. With the
latest "improvement" from Oracle, unless the java.rmi.server.useCodebaseOnly is set to false,
none of this can happen.


On May 1, 2013, at 1131AM, Gregg Wonderly wrote:

> 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 <jini@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.reedy@gmail.com>
>>>>>> FYI, this caused grief yesterday on my project. Some of the team
>>>>>> 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

View raw message