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
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 discovery
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. DownloadPermissio
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 Classload
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 Atom
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.
In
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
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 orig
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
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 Complete Was: OSGi - deseri
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
Orig
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 we
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
implem
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
va
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,
Pe
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
vali
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
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.
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
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 at
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 man
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
-
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
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,
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 o
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, SafeServiceRegistra
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 unde
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 Samsu
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
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 thi
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: 13/02/2017 11:34:45 pm
To: dev@
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 resoluti
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.)"
Sent:
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 Complete Was: OSGi - deseria
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 indentifi
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
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 sur
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 conne
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
deseria
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, th
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 contains
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
42 matches
Mail list logo