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 01:08:38 GMT
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.
>
>   


Mime
View raw message