Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

JGDMS gives you that ability, to grant permission to download an anonymously signed codebase, the authenticated service vouches for it.  It's like this because the free CA "lets encrypt" only signs identity certs, not codebase certs. But we're diverging now. Sent from my Samsung device.     

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

  Input validation only works if failure is atomic.  If an instance of SmartProxyWrapper is created, when a CCE is thrown whilst trying to read in ServiceProxyDownloader because the attacker has chosen to deserialize a gadget chain, the attacker potentially wins. Of course if you implement

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Option 2 consumes minimal memory as sharing is maximised.  Option 1 may be ok in the enterprise, but no good for embedded. Providing option 2 doesn't exclude option 1 and vice versa. Option 1 ties the proxy to the client and if published outside the client, prevents the client bundle

Deserialization vulnerabilities

Right - presented code is just a demonstration of the idea and has to be written with all the precautions you mention. Nevertheless: Do you have any information about how all these deserialization vulnerabilities are affected by simply running the application with SecurityManager? I know of

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

The certs aren't encoded in the codebase annotation, but sent in packets as strings and bytes that are used to reconstruct the certificates during discovery. The certs are also included in the jar file. If Download permission hasn't been granted, the classes can't be defined.  

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Wouldn't it be easier if you simply forbid code downloading during unmarshalling as in SmartProxyWrapper I've shown in another message? Then u use the unmarshalled bootstrap object to securely download the real proxy using existing Jeri implementation. Then you do not need any advanced

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

N.B.  Thanks for discussing, I think all these questions are helping people understand the proposal better and clearing up confusion. If it stands up to scruitiny, then it also provides more confidence in the solution. Regards, Peter. Sent from my Samsung device.     Include original message

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

But what if the client has MULTIPLE clients - each with its own exact API version? OSGi handles this case just fine with service trackers. Do you want to give up on this? Thanks, Michal Peter wrote: You can however for each service api package version, it's all in the smart proxy bundle

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

There are actually two things that we are discussing at the same time: 1. The need to have an "installer" object and how it should be provided to the client 2. The algorithm of class loader resolution in OSGi These two things are orthogonal to each other and your question is about point 2.

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Nope - not at all. I am only trying to convince you that there is no reason to involve ServiceRegistrar or SDM for code downloading. HOW the class resolution is done - is another story. I actually tend to think in a similar way to what Niclas said: Do not use OSGi to load proxy class - create a

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

There a multiple remote services, if one client cant obtain a service because there is also a later version installed then you need a service that doesn't import the later version.  You can still supply another service to cater. Resolution is performed after remote discovery,

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Any Serializable class that implements AtomicSerial can perform input validation. Using one of the secure discovery providers with authentication and input validation.  Download and deserialization permissions are granted dynamically just after authentication, but before download. Regards,

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

My take is a little different, instead services are discovered and registered, then the client can utilise them. The approach you're now suggesting is exactly what Bharath has implented, this is a great first effort and I believe it can be improved.  It's only worked since River 3.0, I think

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Comments inline. Peter wrote: N.B Can't see any chicken egg problem. If service doesn't resolve to same service api as client, then it isn't compatible. The client isn't interested in incompatible services, only those that are compatible This is just an artifact of the dependency

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Peter wrote: In jgdms I've enabled support for https unicast lookup in LookupLocator this establishes a connection to a Registrar only, not any service. This functionality doesn't exist in River. How do you propose establishing a connection using one of these endpoints? I am not sure I

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Then you are vulnerable to deserialization gadget attacks, insecure cyphers anon certs etc.  JGDMS is as secure as possible with current cyphers, no anon certs, no known insecure cyphers (tlsv1.2), input validation during deserialization, delayed unmarshalling with authentication. I don't see

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

So if the CodeDownloadingSmartProxyWrapper implements AtomicSerial then it is fine? Cool - lets do that. Thanks, Michal Peter wrote: Any Serializable class that implements AtomicSerial can perform input validation. Using one of the secure discovery providers with authentication and input

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

KerberosEnpoint? HttpsEndpoint? Thanks, Michal Peter wrote: How do you establish the secure jeri connection? Regards, Peter. Sent from my Samsung device. Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)" Sent:

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

In jgdms I've enabled support for https unicast lookup in LookupLocator this establishes a connection to a Registrar only, not any service.  This functionality doesn't exist in River. How do you propose establishing a connection using one of these endpoints? Regards, Peter. Sent from my

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Peter wrote: There a multiple remote services, if one client cant obtain a service because there is also a later version installed then you need a service that doesn't import the later version. You can still supply another service to cater. This does not scale because you would have to have

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

I fail to understand how you are more vulnerable because of trusted local class that securely downloads code on behalf of a service. And how in terms of security it is different from your SecureServiceRegistrar. Thanks, Michal Peter wrote: Then you are vulnerable to deserialization gadget

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

See below. Peter wrote: Using one of the secure discovery providers with authentication and input validation. Download and deserialization permissions are granted dynamically just after authentication, but before download. But now you just moved trust decisions to SafeServiceRegistrar

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

I changed it to highlite Nic's point that it's not feasible to resolve and provision osgi bundle transitive dependencies during deserialization because the time taken to do that can be excessive due to NP Complete nature of resolution. It is incompatible with stream codebase annotations. I

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

You can however for each service api package version, it's all in the smart proxy bundle manifest. You are bound by the dependency resolution process, the client can only choose from compatible versions.  The service has the power to constrain its proxy bundle manifest if it wishes. Regards,

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

service providers for each api version can still be loaded. But I don't see a way to force all clients to use a single service api version without a compatibility layer.  Why not just reload the clients so they can use the latest compatible version of a service? How does your proposed solution

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

The codebase is signed and download permission is granted only to the signed codebase. Sent from my Samsung device.     Include original message Original message From: Michał Kłeczek Sent: 14/02/2017 01:27:09 am To: dev@river.apache.org Subject: Re: OSGi NP

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Peter wrote: The codebase is signed and download permission is granted only to the signed codebase. What is "signed codebase"? How do you encode the signature in the codebase annotation? Codebase of what service? All of them? Thanks, Michal Sent from my Samsung device. Include

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

It is as simple as: interface ServiceProxyDownloader extends Remote, RemoteMethodControl { Object downloadServiceProxy() throws RemoteException; } //this class is local to the client - to make it more secure it //performs full input validation in readExternal class SmartProxyWrapper

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

It can impliment AtomicSerial and perform input validation.  How do you get from discovery to service without SafeServiceRegistrar lookup? How does your wrapper authenticate the service before codebase and smart proxy download? Sent from my Samsung device.     Include original message

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Both ways have their pros and cons. But the decision whether there should be one proxy instance or more is independent of the decision on how to resolve the proxy class. The latter being much more difficult to design properly. So far we have: 1. Use existing PreferredClassLoader infrastructure

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Comments inline. Peter wrote: Mic, I'm attempting to get my head around your proposal: In the case of JERI, the InvocationHandler is part of the smart proxy's serialized state. A number of smart proxy classes will need to be unmarshalled before the UnmarshallingInvocationHandler is

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

We are talking about the same thing. We are turning circles, Peter - all of this has been already discussed. 1. Yes - you need to resolve bundles in advance (in OSGi it is not possible to do otherwise anyway) 2. You cannot decide upon the bundle chosen by the container to load the proxy class

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Mic, I'm attempting to get my head around your proposal: In the case of JERI, the InvocationHandler is part of the smart proxy's serialized state. A number of smart proxy classes will need to be unmarshalled before the UnmarshallingInvocationHandler is deserialized. The smart proxy

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

To be fair, my position changed somewhat after Nic's email and some further research, it may of course develop further with understanding and experimentation. Cheers, Peter. On 13/02/2017 7:52 PM, Peter wrote: Mic, I'm attempting to get my head around your proposal: In the case of JERI,

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

So this object that you have with a locally installed class is tasked with authenticating the remote service, provisioning and resolving a bundle, deserializing the smart proxy and registering it with the OSGi service registrar in a readResolve or readObject method? How do you propose the

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Sorry, I'm trying to find out the meaning of the current subject line. I'm not sure when it changed to "OSGi MP Complete". On 2/12/2017 10:50 PM, Michał Kłeczek wrote: Sorry, NP Completness of what? I have been the first to mention NP hardness of constraint satisfaction problem but I am not

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

1. The connection can be done using normal (secure) Jeri. We do not have to verify the installer object since its classes were loaded locally and (by definition) are trusted. 2. The attacker cannot instantiate any non-local class. That is the whole point. Since the "installer" classes must be

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

N.B Can't see any chicken egg problem.   If service doesn't resolve to same service api as client, then it isn't compatible.  The client isn't interested in incompatible services, only those that are compatible  This is just an artifact of the dependency resolution process. No bundle

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

How do you establish the secure jeri connection? Regards, Peter. Sent from my Samsung device.     Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)" Sent: 13/02/2017 11:34:45 pm To: dev@river.apache.org Subject: Re: OSGi NP

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

N.B.  No released versions of River / Jini's Jeri are secure now. Ignoring that for a moment, how you establish the connection is important also. Regards, Peter. Sent from my Samsung device.     Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)"