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
