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 AtomicExternal and throw a CCE before the object
superclass method is called, you can prevent your object from being created at
all.
Regards,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Michał Kłeczek <mic...@kleczek.org>
Sent: 14/02/2017 01:55:56 am
To: dev@river.apache.org
Subject: 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 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
>>>>
>>>>
>>
>
>
>
