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 DoS vulnerability that must be prevented additionally. But other?
Most materials on the web don't even mention SecurityManager
and if they do it is only about using SecurityManager only around
deserialization code (which is not secure due to finalizers).
I have an impression that the worst mistake a vendor can do is
to allow turning off security at the very beginning
(to "make life of programmers easier"). After that the product
is blamed for being "insecure" while it is simply a matter of turning
security on.
It happened to MS with Windows (contrary to Unix they made it easy to
run everything with escalated privileges).
It happened to Java (by making SecurityManager turned off the default).
Thanks,
Michal
Peter wrote:
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
