_Unicast Discovery v2 - Unmarshalling Attack with Registrar proxy._
During unicast discovery, we have the option of using SSL, Kerberos or
x500 discovery implementations, unfortunately, if the unicast discovery
implementation being used doesn't comply with constraints for
Authentication and Confidentiality, the constraints are re tried against
the unmarshalled registrar proxy, bypassing the security benefits these
implementations provide.
I believe this was an oversight to allow codebase integrity constraints
to bubble up as Unfulfilled Constraints to the upper layer, where
they're checked against the unmarshalled proxy, unfortunately it appears
to be a mistake to allow Authentication and Confidentiality constraints
to bubble up during discovery.
I think we should change this specifically for Authentication and
Confidentiality constraints, if these are requested but not satisfied
during discovery we should throw an UnsupportedConstraintException.
Doing so avoids the DOS unmarshalling attack which is possible during
unmarshalling of an unauthenticated registrar proxy.
_Unicast Discovery v1_
In light of Unicast Discovery v1's total lack of support for security, I
believe we should deprecate it, for this to happen we also need to
provide a way for existing deployments to migrate.
LookupLocator performs unicast discovery v1.
ConstrainableLookupLocator extends LookupLocator and is used for v2
unicast discovery constraints.
_But what about Multicast Discovery?
_Multicast discovery produces a LookupLocator which is used by Unicast
Discovery to retrieve a registrar proxy.
_Multicast Request Protocol v1
_Please add any security concerns here.
No integrity support - how much of a problem is this?
_Multicast Request Protocol v2
_x500 integrity supported_
__Multicast Announcement Protocol v1
_Please add any security concerns here.
No integrity support, packets can be modified in transit, but this
doesn't seem to be much of a concern for announcement anyway.
_
__Multicast Announcement Protocol v2
_x500 integrity supported.
Note that Multicast v2 supports x500 integrity constraints, in addition
to plain text, while it doesn't prevent someone viewing the contents of
the packet, it ensures the packets contents haven't been tampered with.
I don't see a reason to deprecate Multicast Discovery v1 for existing
deployments, x500 integrity is an obvious advantage, but the real
threat to security occurs during Unicast Discovery, when unmarshalling
attacks can occur.
So we could, in theory at least, use a LookupLocator from Multicast v1
discovery with Unicast v2 discovery in newly deployed clients and
registrars to remain network compatible with existing clients that only
support D v1.
Figuring out how to solve the migration problem?
I think most of the migration problem exists with Multicast, so for
legacy support reasons a djinn could employ Multicast v1 with a
combination of Unicast v1 (for older clients) and v2 for the latter.
Registrar's could have providers for both v1 and v2 discovery and thus
reply to both.
This will require some revisions to discovery utilities (implementing
DiscoveryGroupManagement) for our next release, in order to provide an
upgrade path for existing djinn's.
Any ideas?
Cheers,
Peter.
*
*_
_
--- Begin Message ---
Hi Peter.
I don't remember enough about this to know for sure if this problem is as
stated. I thought the resources were defined in the default Jini 2.0 JAR files,
but that could have changed after my time. Mike Warres was the initial author
of this stuff, but others at Sun took over from him before the effort stopped.
I don't know if any of those guys are still following the conversation.
- Tim
On Dec 12, 2010, at 2:31 PM, Peter Firmstone <j...@zeus.net.au> wrote:
> Tim,
>
> Do you know of an alternative plan to Chris' suggestion, for migration from
> Discovery V1 to V2?
>
> It probably all happened too long ago to remember now, just wondering if
> anything comes to mind?
>
> I'll look into it further too.
>
> Cheers,
>
> Peter.
>> Since its inception, my project has been using DiscoveryV1 and we've
>> never dealt with Jini constraints. Peter's comments last week about the
>> flexibility of DiscoveryV2 inspired me to learn more about it and to
>> experiment a bit. To my surprised, I found it very difficult to figure
>> out how to turn V2 on (I ended up reading a lot of source code), and it
>> looks like it's nearly impossible to migrate in a backward compatible
>> way, i.e. continuing to fully interact with services that were deployed
>> with the default preference for V1. I would LOVE to be told that I've
>> made a mistake or missed something important...
>>
>> * To switch Reggie to use V2 for multicast announcements:
>>
>> com.sun.jini.reggie {
>> discoveryConstraints = new BasicMethodConstraints(new
>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>> }
>>
>> * To switch group discovery to use V2 for multicast requests:
>>
>> net.jini.discovery.LookupDiscovery {
>> discoveryConstraints = new BasicMethodConstraints(new
>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>> }
>>
>> * To create a locator that uses V2 for directed unicast discovery:
>>
>> new ConstrainableLookupLocator(host, port, new
>> BasicMethodConstraints(new InvocationConstraints(null,
>> DiscoveryProtocolVersion.TWO)));
>>
>>
>> * To tell DiscoveryV2 how to encode and decode the messages, create a
>> file called
>> "META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider" and
>> put in lines (for example):
>>
>> com.sun.jini.discovery.plaintext.Client
>> com.sun.jini.discovery.plaintext.Server
>>
>> However (and this is the key problem), any deployed clients or Reggies
>> which lack the
>> META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file
>> will not be able to decode the incoming messages and will drop them with
>> an error message about unknown format IDs.
>>
>> So, the only solution I can see is to start shipping new services with
>> the DiscoveryFormatProvider file in place, and then wait several
>> releases until all of my old deployments have been retired, and then
>> turn on the V2 preference. Am I wrong? Is there a trick to get
>> already-deployed clients to use a format ID that they don't know about?
>> Surely other people have had similar problems deploying brand-new
>> DiscoveryFormatProvider implementations?
>>
>> Is there a way to make services send out both V1 and V2 multicasts? Is
>> there a way to tell LookupDiscovery.UnicastDiscoveryTask to try V2 first
>> and then retry with V1?
>>
>> I feel like I'm missing some central point...
>>
>> Chris
--- End Message ---
