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

Mon, 13 Feb 2017 07:56:21 -0800 

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 implements Externalizable {

  private ServiceProxyDownloader proxyDownloader;

  //the constraints are NOT read from the stream
  //but configured in the client environment
  private MethodConstraints downloadConstraints;

  public void readExternal(ObjectInput input) {

    //this is safe since no code downloading
    //is done by the ObjectInputStream
ServiceProxyDownloader noConstraintsProxyDownloader = input.readObject();
proxyDownloader = noConstraintsProxyDownloader.setConstraints(downloadConstraints); 

  }

  Object readResolve() throws ObjectStreamException {
    try {
      return proxyDownloader.downloadServiceProxy();
    }
    catch (Exception e) {
      //handle aproprietly
    }
  }

}

Thanks,
Michal

Peter wrote:

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 
---- Original message ----
From: Michał Kłeczek<mic...@kleczek.org>
Sent: 14/02/2017 01:21:46 am
To: dev@river.apache.org
Subject: 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 
validation.  Download and deserialization permissions are granted dynamically 
just after authentication, but before download.

  Regards,

  Peter.

  Sent from my Samsung device.
Include original message 
  ---- Original message ----
  From: Michał Kłeczek<mic...@kleczek.org>
  Sent: 14/02/2017 01:13:04 am
  To: dev@river.apache.org
  Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation 
strategy
So your SaveUnmarshallingProxy can do input validation fist as well, can't it?
BTW - how does the client unmarshalls SafeServiceRegistrar proxy in a secure way? 

  Thanks,
  Michal

  Peter wrote:

    I did notice that.

    Are you comnnected to a network and performing deserialization without 
input validation?   Does the secure endpoint allow anon clients?  That is even 
if you are using client certificates does the endpoint allow anon?  Does your 
endpoint allow insecure cyphers?

    Have a look at the changes in JGDMS.

    SafeServiceRegistrar authenticates and performs input validation first.

    Regards,

    Peter.

    Sent from my Samsung device.
Include original message 
    ---- Original message ----
    From: Michał Kłeczek<mic...@kleczek.org>
    Sent: 14/02/2017 12:42:43 am
    To: dev@river.apache.org
    Subject: 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 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 why a compelling reason to give that up for a local class 
with a readResolve method?

      Sorry.

      Regards,

      Peter.
      Sent from my Samsung device.
Include original message 
      ---- Original message ----
      From: Michał Kłeczek<mic...@kleczek.org>
      Sent: 14/02/2017 12:14:41 am
      To: dev@river.apache.org
      Subject: 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 understand the question.
In exactly the same way how today the connection is established by for example a ProxyTrust instance 

      Thanks,
      Michal

Reply via email to