river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: JDK 7 Enhancements just bit me again
Date Wed, 01 May 2013 21:11:10 GMT
The problem we have is the way the JERI endpoints are used.

We first unmarshall a proxy, then we place constraints on it to ensure the connection is secure.

None of the existing mechanisms can prevent an attacker from using deserialization to pown
the system if we share lookup services.

Secure discovery on the other hand has discovery constraints that are enforced prior to downloading.

The original team that wrote JERI provided mechanism to do this safely, but because of backward
compatibility requirements, there's no way to pass these constraints to the lookup service
to ensure the constraints are applied prior to unmarshalling a ServiceItem.

The lookup service proxy unmarshalls the proxy locally on our behalf without authenicating
the connection with the third party.

If the lookup service allows a third party client service to register a proxy over an insecure
connection and I, a client require a secure connection, I have no way of ensuring I only recieve
lookup results that have authenticated over a secure connection with the lookup service.

Presently you cannot share lookup services with other entities securely, you have to own the
lookup service and ensure all clients authenticate and you must use secure discovery.

Peter.

----- Original message -----
> 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.
>
> Dennis
>
> 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>
> > > > > > 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
> > > >
> > >
> >
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message