river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: [jira] Created: (RIVER-362) Denial of Service during unmarshalling of smart proxy's
Date Mon, 18 Oct 2010 21:28:25 GMT
Thanks Michal,

If you log into JIRA, it has an upload feature, you can attach the code 
directly to the issue and grant an AL2 license at the same time.




Michal Kleczek wrote:
> Folks,
> I've managed to create a prototype implementation of the idea of annotating 
> classes with Modules.
> Working on this allowed me to learn quite a lot about inner workings of River 
> - the original implementation that I've presented before had to be modified 
> (not saying it had to be fixed :) ) but the main idea stayed the same. This 
> time I think it really covers more use cases.
> Shortly:
> 1. We allow annotating classes with Modules. A Module is an object responsible 
> for loading classes.
> 2. There is a new RMIClassLoaderSpi implementation which I called 
> ModuleClassProvider
> 3. ModuleClassProvider manages installed Modules
> 4. It also can load classes based on String annotations which are expected to 
> be either
> a) serialized and Base64 encoded Module - the Module is deserialized and 
> handled as any other Module annotation
> b) an old style list of URLs - class loading is delegated to 
> RequireDlPermProvider - in other words we either load classes from Modules 
> (which are verified for trust before use) or from URLs but then we require 
> appropriate DownloadPermissions
> Attached is a multi-module maven project. The modules are:
> 1. secure-marshall-stream (which is the implementation of all this + some not 
> yet finished additional code)
> 2. jsk-module-platform which contains modified Jini classes so that it all 
> works with existing Jini services (to be honest only ClassLoading really 
> needed to change. MarshalInputStream/MarshalOutputStream/MarshalledInstance 
> are changed only to avoid having serialized and Base64 encoded Modules as 
> annotations
> To run it you need to put jsk-module-platform before jsk-platform on the 
> classpath (and of course add secure-marshall-stream as well)
> Existing services can be exported with a ModuleExporter:
>     private serviceILFactory =
> 	new ProxyTrustILFactory(serviceConstraints,
>                                 RegistrarPermission.class);
>     private moduleTrustILFactory =
> 	new ModuleTrustILFactory(serviceConstraints,
>                                 null);
>     serverExporter = new ModuleExporter(new BasicJeriExporter(serviceEndpoint, 
> serviceILFactory), new BasicJeriExporter(serviceEndpoint, 
> moduleTrustILFactory));
> I've done some basic scenario testing which was running Reggie and Service 
> Browser installed by Jini 2.1 installer. Both Browser and Reggie policies did 
> not grant any DownloadPermissions.
> When exported with BasicJeriExporter lookup of ServiceRegistrar by the Browser 
> failed with missing DownloadPermission.
> When exported with ModuleExporter both Reggie and Browser used 
> ProxyTrustVerifier to verifify Modules.
> Note - this is strictly a prototype - no comments / junit tests / code reviews 
> and no real testing.
> If you have any questions / comments - you're very welcome.
> Michal
> On Monday 18 of October 2010 03:08:38 Peter Firmstone wrote:
>> Notes for fix:
>> DownloadPermission protects against unauthenticated downloads
>> ClassLoadingPermission - new Permission to protect against
>> unauthenticated Class loading.
>> Issues we're addressing in the DOS hole:
>>     * Eliminate unauthenticated URL downloads.
>>     * Eliminate unmarshalling of unauthenticated code.
>>     * Eliminate execution of unauthenticated code.
>>     * Eliminate StackOverflowError's in the client thread, caused by
>>       sending spurious garbage over InputStream's.
>>     * Eliminate StackOverflowError's in the client thread, caused by
>>       substituted jar files or URL's from DNS cache poisoning attacks etc.
>> How?
>>     * Delay granting DownloadPermission, until remote endpoint has
>>       authenticated itself, we trust the remote endpoint to advise a
>>       suitable URL, if it authenticates.
>>     * Authentication by annotating a reflective proxy (additional to the
>>       Codebase String) from the remote endpoint, used for authentication
>>       and to provide CodeSource Certificate[]'s.  This may be different
>>       to the Service, if a remote object is marshalled elsewhere (eg
>>       another client).
>>     * Delay granting ClassLoadingPermission, until remote endpoint has
>>       authenticated itself and has provided the expected CodeSource
>>       Certificate[]'s
>>     * Perform unmarshalling in a controlled ExecutorService thread.
>> So all we're doing different is authenticating the remote end and if it
>> authenticates permit downloading and classloading.
>> There is one more scenario to consider, currently this is a mechanism to
>> protect against download and deserialization of unknown code for smart
>> proxy's.  But what about Service that only use reflective proxy's and
>> don't require downloaded code?
>> But what if we don't want to grant download permission or class loading
>> permission to a Subject we authenticate?
>> Currently the unmarshalling code doesn't run as the Subject after
>> authentication, this means the Permission grant's are only dependent on
>> authentication, something Michal pointed out earlier when this was
>> proposed.
>> Now this code can be easily changed so the granting permission operation
>> is run as the Subject after authentication, this would allow us to
>> distinguish between different Subjects.
>> The drawback is that performance won't be as good, but it seems the most
>> logical and powerful approach.
>> What do you think?
>> There is one last obstacle, if Certificates are used to sign the jar
>> files, how do you effectively prevent one Subject from using another
>> Subject's signed CodeSource's if Code signing is used for isolation of
>> separate Subjects namespaces?  A service could deliberately attempt to
>> occupy the same namespace as another Service to attempt to gain
>> information via shared static variables.  We need to prevent this
>> occurring.
>> This has to be done with the ClassLoader, but during unmarshalling, the
>> service proxy has not yet been verified.  The authentication proxy
>> delivered with the MarshalInputStream may not have the same Subject as
>> the Service, it could be a third party.
>> Could it be that when the smart proxy is unmarshalled, and executed as
>> it's Subject, it must contain a Certificate matching the signer of the
>> Codebase?
>> We're on the cusp of solving this problem, thoughts?
>> Cheers,
>> Peter.
>> Peter Firmstone (JIRA) wrote:
>>> Denial of Service during unmarshalling of smart proxy's
>>> -------------------------------------------------------
>>>                  Key: RIVER-362
>>>                  URL: https://issues.apache.org/jira/browse/RIVER-362
>>>              Project: River
>>>           Issue Type: Bug
>>>          Environment: Untrusted networks
>>>             Reporter: Peter Firmstone
>>> During unmarshalling of smart proxy's there's a period before the proxy
>>> has been verified (authenticated) where deserialization methods are
>>> executed on untrusted code, the potential exists for untrusted code to
>>> perform denial of service.

View raw message