river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <mic...@kleczek.org>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Mon, 13 Feb 2017 15:21:46 GMT
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<michal@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<michal@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<michal@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
>>>
>>>
>>
>
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message