You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dennis Reedy <de...@gmail.com> on 2013/04/30 13:53:01 UTC
JDK 7 Enhancements just bit me again
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
Re: JDK 7 Enhancements just bit me again
Posted by Peter <ji...@zeus.net.au>.
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 <ji...@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<de...@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
> > > >
> > >
> >
>
Re: JDK 7 Enhancements just bit me again
Posted by Dennis Reedy <de...@gmail.com>.
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 <ji...@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<de...@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
>>>
>>
>
Re: JDK 7 Enhancements just bit me again
Posted by Gregg Wonderly <ge...@cox.net>.
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 <ji...@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<de...@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
>>
>
Re: JDK 7 Enhancements just bit me again
Posted by Peter Firmstone <ji...@zeus.net.au>.
Instead of putting the proxy in the String annotation, can it go in an
additional byte array in MarshalledInstance?
This can be used by a trusted lookup service proxy to perform trust
operations on behalf of the client.
During marshalling, if the first Proxy implementing ProxyTrust found in
the stream could be replaced by a token, then serialized into another
array. During unmarshalling, the Proxy would be restricted to the
trusted classes required for proxy verification. Because these are
trusted local classes the proxy doesn't require any annotation to be
unmarshalled.
The proxy could also implement another interface, which after verifying
it's a trusted object and applying constraints, could be requested to
provide an array string of all classes it wishes to unmarshall. Now
since we trust the proxy and have authenticated, we're now preventing a
third party that may have intercepted the stream, from doing harm.
In addition we might ask the proxy for Certificate signers for the
codebase. We could even ask it for the codebase annotation, if we wanted.
At this point the bootstrap proxy is trusted, so we're ready to
unmarshall a smart proxy, if it exists and replace the token that was
inserted during marshalling, with the bootstrap proxy.
Unmarshalling this remote object we could ensure the jar file is signed
by the correct Certificates, and restrict unmarshalling to the list of
classes supplied by the bootstrap proxy.
After unmarshalling we could apply constraints to the smart proxy and
return a fully prepared proxy to the client, resulting in simpler client
code.
Regards,
Peter.
Peter Firmstone wrote:
>
>
> On 3/05/2013 12:22 AM, Michal Kleczek wrote:
>> So the problems to solve are:
>> 1. Possible buffer overflow and DoS type of attacks - since we do not
>> authenticate the stream before deserialization of the first object an
>> attacker can possibly inject huge objects (of classes available
>> locally) in the stream (such as LinkedList of arbitrary size).
>> 2. Leverage of vulnerabilities in classes available locally during
>> object deserialization.
>>
>> Limiting the list of classes that can be instantiated before doing
>> codebase verification is a good idea that could possibly solve both
>> issues. That would be basically providing a small Trusted Computing
>> Base for security checking of downloaded code.
>> But that actually means that codebase annotations _should_ be objects
>> that implement their deserialization in a secure manner so that
>> attacks from point 1. are not possible. As of today we use
>> java.lang.String which does not put any constraints on its size.
>
> Objects themselves have no way of limiting the size of the stream
> transferred, unless they only read a limited number of bytes and avoid
> calling readObject() on the stream, but that's very restrictive and
> this would place an unnecessary implementation burden on our trusted
> computing base, which would have to be careful not to download
> excessive bytes too.
>
> We need to limit the bytes read from the stream until trust is
> verified, we could do that by wrapping the InputStream passed to the
> MarshalInputStream constructor and counting the bytes read until we
> reach our limit, resulting in an IOException and closing the stream,
> otherwise the proxy is verified and we set a boolean value to stop
> counting prior to reaching the limit.
>
> So we are very close to the solution, but I don't feel that ah-ha
> moment yet. I'm off to bed now to sleep on it.
>
> Cheers,
>
> Peter.
>
>>
>> To provide backward compatibility we could fall back to old
>> implementation in case the class is not part of TCB. We would only
>> allow it if the stream is authenticated beforehand.
>>
>> Michal
>>
>> On 2013-05-02 15:35, Peter Firmstone wrote:
>>> On 2/05/2013 9:32 PM, Michal Kleczek wrote:
>>>>>
>>>>> An attacker can use a serialization attack, without requiring
>>>>> jini, to create a ClassLoader and start downloading classes out of
>>>>> band.
>>>>
>>>> Given you never execute untrusted code: how?
>>>>
>>>
>>> I'm glad you asked me this question, because I just stumbled over a
>>> partial solution:
>>>
>>> http://www.ibm.com/developerworks/library/se-lookahead/index.html
>>>
>>> Ironically I went looking for an example on the web for you, but
>>> this article instead, completely unexpected, this article is very
>>> good because it describes the issues with serialization well. The
>>> article was only written in January this year.
>>>
>>> Just possibly we could restrict the classes that
>>> MarshaledInputStream can instantiate to only those required to
>>> perform proxy verification.
>>>
>>> Could we limit both the bytes read from the stream and the classes
>>> (required for connection and proxy trust) deserialized from the
>>> stream until proxy verification has been performed?
>>>
>>> The challenge is, how can we do this and retain backward
>>> compatibility in marshalled object streams?
>>>
>>> If there's an answer to those questions, it's the security grail for
>>> Jini the Sun team was looking for.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>
>>
>
>
Re: JDK 7 Enhancements just bit me again
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok fair comment.
On 4/05/2013 3:54 PM, Dan Creswell wrote:
> How about logging a JIRA ticket with the conversation and tagging it for
> say 2.4.0?
>
> On 4 May 2013 02:49, Dennis Reedy<de...@gmail.com> wrote:
>
>> A suggestion. I think this is a very interesting thread, but I really want
>> to suggest that we stop. There have been so many changes put into 2.3.0
>> that need to be reviewed, documented and released. Lets make a concerted
>> effort to get that done before we make more changes.
>>
>> Regards
>>
>> Dennis
>>
>> On May 2, 2013, at 1048AM, Peter Firmstone wrote:
>>
>>>
>>> On 3/05/2013 12:22 AM, Michal Kleczek wrote:
>>>> So the problems to solve are:
>>>> 1. Possible buffer overflow and DoS type of attacks - since we do not
>> authenticate the stream before deserialization of the first object an
>> attacker can possibly inject huge objects (of classes available locally) in
>> the stream (such as LinkedList of arbitrary size).
>>>> 2. Leverage of vulnerabilities in classes available locally during
>> object deserialization.
>>>> Limiting the list of classes that can be instantiated before doing
>> codebase verification is a good idea that could possibly solve both issues.
>> That would be basically providing a small Trusted Computing Base for
>> security checking of downloaded code.
>>>> But that actually means that codebase annotations _should_ be objects
>> that implement their deserialization in a secure manner so that attacks
>> from point 1. are not possible. As of today we use java.lang.String which
>> does not put any constraints on its size.
>>> Objects themselves have no way of limiting the size of the stream
>> transferred, unless they only read a limited number of bytes and avoid
>> calling readObject() on the stream, but that's very restrictive and this
>> would place an unnecessary implementation burden on our trusted computing
>> base, which would have to be careful not to download excessive bytes too.
>>> We need to limit the bytes read from the stream until trust is verified,
>> we could do that by wrapping the InputStream passed to the
>> MarshalInputStream constructor and counting the bytes read until we reach
>> our limit, resulting in an IOException and closing the stream, otherwise
>> the proxy is verified and we set a boolean value to stop counting prior to
>> reaching the limit.
>>> So we are very close to the solution, but I don't feel that ah-ha moment
>> yet. I'm off to bed now to sleep on it.
>>> Cheers,
>>>
>>> Peter.
>>>
>>>> To provide backward compatibility we could fall back to old
>> implementation in case the class is not part of TCB. We would only allow it
>> if the stream is authenticated beforehand.
>>>> Michal
>>>>
>>>> On 2013-05-02 15:35, Peter Firmstone wrote:
>>>>> On 2/05/2013 9:32 PM, Michal Kleczek wrote:
>>>>>>> An attacker can use a serialization attack, without requiring jini,
>> to create a ClassLoader and start downloading classes out of band.
>>>>>> Given you never execute untrusted code: how?
>>>>>>
>>>>> I'm glad you asked me this question, because I just stumbled over a
>> partial solution:
>>>>> http://www.ibm.com/developerworks/library/se-lookahead/index.html
>>>>>
>>>>> Ironically I went looking for an example on the web for you, but this
>> article instead, completely unexpected, this article is very good because
>> it describes the issues with serialization well. The article was only
>> written in January this year.
>>>>> Just possibly we could restrict the classes that MarshaledInputStream
>> can instantiate to only those required to perform proxy verification.
>>>>> Could we limit both the bytes read from the stream and the classes
>> (required for connection and proxy trust) deserialized from the stream
>> until proxy verification has been performed?
>>>>> The challenge is, how can we do this and retain backward compatibility
>> in marshalled object streams?
>>>>> If there's an answer to those questions, it's the security grail for
>> Jini the Sun team was looking for.
>>>>> Cheers,
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>
>>
Re: JDK 7 Enhancements just bit me again
Posted by Dan Creswell <da...@gmail.com>.
How about logging a JIRA ticket with the conversation and tagging it for
say 2.4.0?
On 4 May 2013 02:49, Dennis Reedy <de...@gmail.com> wrote:
> A suggestion. I think this is a very interesting thread, but I really want
> to suggest that we stop. There have been so many changes put into 2.3.0
> that need to be reviewed, documented and released. Lets make a concerted
> effort to get that done before we make more changes.
>
> Regards
>
> Dennis
>
> On May 2, 2013, at 1048AM, Peter Firmstone wrote:
>
> >
> >
> > On 3/05/2013 12:22 AM, Michal Kleczek wrote:
> >> So the problems to solve are:
> >> 1. Possible buffer overflow and DoS type of attacks - since we do not
> authenticate the stream before deserialization of the first object an
> attacker can possibly inject huge objects (of classes available locally) in
> the stream (such as LinkedList of arbitrary size).
> >> 2. Leverage of vulnerabilities in classes available locally during
> object deserialization.
> >>
> >> Limiting the list of classes that can be instantiated before doing
> codebase verification is a good idea that could possibly solve both issues.
> That would be basically providing a small Trusted Computing Base for
> security checking of downloaded code.
> >> But that actually means that codebase annotations _should_ be objects
> that implement their deserialization in a secure manner so that attacks
> from point 1. are not possible. As of today we use java.lang.String which
> does not put any constraints on its size.
> >
> > Objects themselves have no way of limiting the size of the stream
> transferred, unless they only read a limited number of bytes and avoid
> calling readObject() on the stream, but that's very restrictive and this
> would place an unnecessary implementation burden on our trusted computing
> base, which would have to be careful not to download excessive bytes too.
> >
> > We need to limit the bytes read from the stream until trust is verified,
> we could do that by wrapping the InputStream passed to the
> MarshalInputStream constructor and counting the bytes read until we reach
> our limit, resulting in an IOException and closing the stream, otherwise
> the proxy is verified and we set a boolean value to stop counting prior to
> reaching the limit.
> >
> > So we are very close to the solution, but I don't feel that ah-ha moment
> yet. I'm off to bed now to sleep on it.
> >
> > Cheers,
> >
> > Peter.
> >
> >>
> >> To provide backward compatibility we could fall back to old
> implementation in case the class is not part of TCB. We would only allow it
> if the stream is authenticated beforehand.
> >>
> >> Michal
> >>
> >> On 2013-05-02 15:35, Peter Firmstone wrote:
> >>> On 2/05/2013 9:32 PM, Michal Kleczek wrote:
> >>>>>
> >>>>> An attacker can use a serialization attack, without requiring jini,
> to create a ClassLoader and start downloading classes out of band.
> >>>>
> >>>> Given you never execute untrusted code: how?
> >>>>
> >>>
> >>> I'm glad you asked me this question, because I just stumbled over a
> partial solution:
> >>>
> >>> http://www.ibm.com/developerworks/library/se-lookahead/index.html
> >>>
> >>> Ironically I went looking for an example on the web for you, but this
> article instead, completely unexpected, this article is very good because
> it describes the issues with serialization well. The article was only
> written in January this year.
> >>>
> >>> Just possibly we could restrict the classes that MarshaledInputStream
> can instantiate to only those required to perform proxy verification.
> >>>
> >>> Could we limit both the bytes read from the stream and the classes
> (required for connection and proxy trust) deserialized from the stream
> until proxy verification has been performed?
> >>>
> >>> The challenge is, how can we do this and retain backward compatibility
> in marshalled object streams?
> >>>
> >>> If there's an answer to those questions, it's the security grail for
> Jini the Sun team was looking for.
> >>>
> >>> Cheers,
> >>>
> >>> Peter.
> >>>
> >>>
> >>
> >>
> >
>
>
Re: JDK 7 Enhancements just bit me again
Posted by Dennis Reedy <de...@gmail.com>.
A suggestion. I think this is a very interesting thread, but I really want to suggest that we stop. There have been so many changes put into 2.3.0 that need to be reviewed, documented and released. Lets make a concerted effort to get that done before we make more changes.
Regards
Dennis
On May 2, 2013, at 1048AM, Peter Firmstone wrote:
>
>
> On 3/05/2013 12:22 AM, Michal Kleczek wrote:
>> So the problems to solve are:
>> 1. Possible buffer overflow and DoS type of attacks - since we do not authenticate the stream before deserialization of the first object an attacker can possibly inject huge objects (of classes available locally) in the stream (such as LinkedList of arbitrary size).
>> 2. Leverage of vulnerabilities in classes available locally during object deserialization.
>>
>> Limiting the list of classes that can be instantiated before doing codebase verification is a good idea that could possibly solve both issues. That would be basically providing a small Trusted Computing Base for security checking of downloaded code.
>> But that actually means that codebase annotations _should_ be objects that implement their deserialization in a secure manner so that attacks from point 1. are not possible. As of today we use java.lang.String which does not put any constraints on its size.
>
> Objects themselves have no way of limiting the size of the stream transferred, unless they only read a limited number of bytes and avoid calling readObject() on the stream, but that's very restrictive and this would place an unnecessary implementation burden on our trusted computing base, which would have to be careful not to download excessive bytes too.
>
> We need to limit the bytes read from the stream until trust is verified, we could do that by wrapping the InputStream passed to the MarshalInputStream constructor and counting the bytes read until we reach our limit, resulting in an IOException and closing the stream, otherwise the proxy is verified and we set a boolean value to stop counting prior to reaching the limit.
>
> So we are very close to the solution, but I don't feel that ah-ha moment yet. I'm off to bed now to sleep on it.
>
> Cheers,
>
> Peter.
>
>>
>> To provide backward compatibility we could fall back to old implementation in case the class is not part of TCB. We would only allow it if the stream is authenticated beforehand.
>>
>> Michal
>>
>> On 2013-05-02 15:35, Peter Firmstone wrote:
>>> On 2/05/2013 9:32 PM, Michal Kleczek wrote:
>>>>>
>>>>> An attacker can use a serialization attack, without requiring jini, to create a ClassLoader and start downloading classes out of band.
>>>>
>>>> Given you never execute untrusted code: how?
>>>>
>>>
>>> I'm glad you asked me this question, because I just stumbled over a partial solution:
>>>
>>> http://www.ibm.com/developerworks/library/se-lookahead/index.html
>>>
>>> Ironically I went looking for an example on the web for you, but this article instead, completely unexpected, this article is very good because it describes the issues with serialization well. The article was only written in January this year.
>>>
>>> Just possibly we could restrict the classes that MarshaledInputStream can instantiate to only those required to perform proxy verification.
>>>
>>> Could we limit both the bytes read from the stream and the classes (required for connection and proxy trust) deserialized from the stream until proxy verification has been performed?
>>>
>>> The challenge is, how can we do this and retain backward compatibility in marshalled object streams?
>>>
>>> If there's an answer to those questions, it's the security grail for Jini the Sun team was looking for.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>
>>
>
Re: JDK 7 Enhancements just bit me again
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 3/05/2013 12:22 AM, Michal Kleczek wrote:
> So the problems to solve are:
> 1. Possible buffer overflow and DoS type of attacks - since we do not
> authenticate the stream before deserialization of the first object an
> attacker can possibly inject huge objects (of classes available
> locally) in the stream (such as LinkedList of arbitrary size).
> 2. Leverage of vulnerabilities in classes available locally during
> object deserialization.
>
> Limiting the list of classes that can be instantiated before doing
> codebase verification is a good idea that could possibly solve both
> issues. That would be basically providing a small Trusted Computing
> Base for security checking of downloaded code.
> But that actually means that codebase annotations _should_ be objects
> that implement their deserialization in a secure manner so that
> attacks from point 1. are not possible. As of today we use
> java.lang.String which does not put any constraints on its size.
Objects themselves have no way of limiting the size of the stream
transferred, unless they only read a limited number of bytes and avoid
calling readObject() on the stream, but that's very restrictive and this
would place an unnecessary implementation burden on our trusted
computing base, which would have to be careful not to download excessive
bytes too.
We need to limit the bytes read from the stream until trust is verified,
we could do that by wrapping the InputStream passed to the
MarshalInputStream constructor and counting the bytes read until we
reach our limit, resulting in an IOException and closing the stream,
otherwise the proxy is verified and we set a boolean value to stop
counting prior to reaching the limit.
So we are very close to the solution, but I don't feel that ah-ha moment
yet. I'm off to bed now to sleep on it.
Cheers,
Peter.
>
> To provide backward compatibility we could fall back to old
> implementation in case the class is not part of TCB. We would only
> allow it if the stream is authenticated beforehand.
>
> Michal
>
> On 2013-05-02 15:35, Peter Firmstone wrote:
>> On 2/05/2013 9:32 PM, Michal Kleczek wrote:
>>>>
>>>> An attacker can use a serialization attack, without requiring jini,
>>>> to create a ClassLoader and start downloading classes out of band.
>>>
>>> Given you never execute untrusted code: how?
>>>
>>
>> I'm glad you asked me this question, because I just stumbled over a
>> partial solution:
>>
>> http://www.ibm.com/developerworks/library/se-lookahead/index.html
>>
>> Ironically I went looking for an example on the web for you, but this
>> article instead, completely unexpected, this article is very good
>> because it describes the issues with serialization well. The article
>> was only written in January this year.
>>
>> Just possibly we could restrict the classes that MarshaledInputStream
>> can instantiate to only those required to perform proxy verification.
>>
>> Could we limit both the bytes read from the stream and the classes
>> (required for connection and proxy trust) deserialized from the
>> stream until proxy verification has been performed?
>>
>> The challenge is, how can we do this and retain backward
>> compatibility in marshalled object streams?
>>
>> If there's an answer to those questions, it's the security grail for
>> Jini the Sun team was looking for.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>
>
Re: JDK 7 Enhancements just bit me again
Posted by Michal Kleczek <mi...@xpro.biz>.
So the problems to solve are:
1. Possible buffer overflow and DoS type of attacks - since we do not
authenticate the stream before deserialization of the first object an
attacker can possibly inject huge objects (of classes available locally)
in the stream (such as LinkedList of arbitrary size).
2. Leverage of vulnerabilities in classes available locally during
object deserialization.
Limiting the list of classes that can be instantiated before doing
codebase verification is a good idea that could possibly solve both
issues. That would be basically providing a small Trusted Computing Base
for security checking of downloaded code.
But that actually means that codebase annotations _should_ be objects
that implement their deserialization in a secure manner so that attacks
from point 1. are not possible. As of today we use java.lang.String
which does not put any constraints on its size.
To provide backward compatibility we could fall back to old
implementation in case the class is not part of TCB. We would only allow
it if the stream is authenticated beforehand.
Michal
On 2013-05-02 15:35, Peter Firmstone wrote:
> On 2/05/2013 9:32 PM, Michal Kleczek wrote:
>>>
>>> An attacker can use a serialization attack, without requiring jini,
>>> to create a ClassLoader and start downloading classes out of band.
>>
>> Given you never execute untrusted code: how?
>>
>
> I'm glad you asked me this question, because I just stumbled over a
> partial solution:
>
> http://www.ibm.com/developerworks/library/se-lookahead/index.html
>
> Ironically I went looking for an example on the web for you, but this
> article instead, completely unexpected, this article is very good
> because it describes the issues with serialization well. The article
> was only written in January this year.
>
> Just possibly we could restrict the classes that MarshaledInputStream
> can instantiate to only those required to perform proxy verification.
>
> Could we limit both the bytes read from the stream and the classes
> (required for connection and proxy trust) deserialized from the stream
> until proxy verification has been performed?
>
> The challenge is, how can we do this and retain backward compatibility
> in marshalled object streams?
>
> If there's an answer to those questions, it's the security grail for
> Jini the Sun team was looking for.
>
> Cheers,
>
> Peter.
>
>
--
Michał Kłeczek
XPro Quality Matters
http://www.xpro.biz
Re: JDK 7 Enhancements just bit me again
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 2/05/2013 9:32 PM, Michal Kleczek wrote:
>>
>> An attacker can use a serialization attack, without requiring jini,
>> to create a ClassLoader and start downloading classes out of band.
>
> Given you never execute untrusted code: how?
>
I'm glad you asked me this question, because I just stumbled over a
partial solution:
http://www.ibm.com/developerworks/library/se-lookahead/index.html
Ironically I went looking for an example on the web for you, but this
article instead, completely unexpected, this article is very good
because it describes the issues with serialization well. The article
was only written in January this year.
Just possibly we could restrict the classes that MarshaledInputStream
can instantiate to only those required to perform proxy verification.
Could we limit both the bytes read from the stream and the classes
(required for connection and proxy trust) deserialized from the stream
until proxy verification has been performed?
The challenge is, how can we do this and retain backward compatibility
in marshalled object streams?
If there's an answer to those questions, it's the security grail for
Jini the Sun team was looking for.
Cheers,
Peter.
Re: JDK 7 Enhancements just bit me again
Posted by Michal Kleczek <mi...@xpro.biz>.
On 2013-05-01 23:21, Peter wrote:
> The annotation must be deserialized, serialization itself is insecure, we need to authenticate using a secure connection, prior to deserializing that annotation.
In my scheme you _do_ authenticate before deserializing the annotation.
By means of ProxyTrustVerifier that verified the annotation of annotation.
To deserialize an object we need to have code already in memory. The
whole point is to make sure this code is trusted prior to execution. It
can be:
1. local (trusted by definition)
2. downloaded from a trusted source (eg. an SSL connection to a trusted
Registrar and http server)
3. downloaded from untrusted source and verified prior to execution
Actually the whole idea of code signing is that you can download code
from an untrusted source and still be able to verify it.
In Jini we already have something equivalent but we verify objects
(code+data). ProxyTrustVerifier makes sure a trusted party (possibly
even a trusted third party) can verify _any_ object (in particular a
service proxy). Once you represent downloaded code as an object you can
use existing mechanisms to verify code. That way it does not matter
where the object (be it a service proxy or a codebase annotation) comes
from. It could have been sent as an email attachment - how it is
downloaded is orthogonal to the fact that we never execute untrusted code.
>
> An attacker can use a serialization attack, without requiring jini, to create a ClassLoader and start downloading classes out of band.
>
Given you never execute untrusted code: how?
> 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.
--
Michał Kłeczek
XPro Quality Matters
http://www.xpro.biz
Re: JDK 7 Enhancements just bit me again
Posted by Peter <ji...@zeus.net.au>.
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<de...@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
>
Re: JDK 7 Enhancements just bit me again
Posted by Michal Kleczek <mi...@xpro.biz>.
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<de...@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
Re: JDK 7 Enhancements just bit me again
Posted by Peter <ji...@zeus.net.au>.
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<de...@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
>
Re: JDK 7 Enhancements just bit me again
Posted by Michal Kleczek <mi...@xpro.biz>.
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<de...@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
Re: JDK 7 Enhancements just bit me again
Posted by Peter Firmstone <ji...@zeus.net.au>.
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<de...@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
>
Re: JDK 7 Enhancements just bit me again
Posted by Gregg Wonderly <ge...@cox.net>.
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 <de...@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