[e-lang] Security Implications of Multimethods?

Sandro Magi smagi at naasking.homeip.net
Tue Feb 28 08:41:33 EST 2006


David Hopwood wrote:
> Sandro Magi wrote:
> 
>>I've recently been reading up on multimethods and multiple dispatch
>>(see: http://nice.sourceforge.net/). While attractive in some
>>circumstances, they make me a bit uneasy; I feel there might be
>>something potentially sinister lurking beneath the surface.
>>
>>So when in doubt, ask: what are the security implications of
>>multimethods and symmetric or asymmetric multiple dispatch?
> 
> 
> It depends on how they are defined in a particular language.
> 
> In a typical single-dispatch capability-secure language, restrictions on
> access to the private variables of an object are enforced by lexical scoping --
> only the code for which these variables are in scope can access them.
> (This is independent of whether objects are defined using processes, prototypes,
> classes, or closures.)
> 
> The simplest way to define a multiple-dispatch or predicate-dispatch language
> involves dropping this scoping requirement, allowing any code to define methods
> that can access the private data of any object. This is clearly insecure from a
> capability security point of view.

Certainly if you restrict the multimethods to utilizing only the public 
interface, then the above isn't an issue. I'm worried about more 
insidious security issues though, that developers might not expect (see 
below).

> There are at least two alternatives that are more secure:
> 
> 1. still use scoping to control which code can access an object's private data,
>    but allow the specification of which scopes can access a given object
>    definition to be more flexible.
> 
> 2. require that to access private data it is necessary to hold a capability
>    associated with the object definition. I.e. each object's private data is
>    essentially sealed, and requires an unsealer to access it.
> 
> Either is in principle acceptable for a capability-secure language; the
> latter is more expressive (since the unsealer capability *can* be given to
> any code), but requires more security analysis when used in its full
> generality.

I hadn't even considered #2. Interesting. :-)

How about less-obvious issues, like dispatching to code that wasn't 
present when the original object was written?

For instance, assume a server with its own private thread (to protect 
itself from malicious clients) loads a confined piece of malicious code 
which defines the most specific multimethod to which the server would 
dispatch. This is pseudo-java, which can't really support this level of 
security, but let's assume it can:

package naive.server;
public class DispatchA {}
public class DispatchB {}

public class VulnerableServer {
   Queue messages;
   public void send(DispatchA a) {
     messages.push(a); //client thread
   }
   public void run(DispatchA a) {
     DispatchA a = messages.pop(); //server thread
     doSomeWork(a, new DispatchB());
   }
   ...
   public void doSomeWork(DispatchA a, DispatchB b) {
     //server expects it to dispatch to some known code
     //which doesn't leave it vulnerable
   }
}

package malicious.client;
public class ConfinedMaliciousClient {
   class A extends DispatchA {}
   ...
   void exploitVulnerability() {
     VulnerableServer.send(new A());
   }
   public void doSomeWork(A a, DispatchB b) {
     //malicious client has now captured the server's thread
   }
}

This particular example depends on global multimethods (where resolution 
is global at link time rather than confined to a specific package -- I 
believe Nice supports this), but I think even scoped-multimethods (where 
resolution is confined to a particular package) can be vulnerable to 
this given a particular configuration.

Sandro

> (I was intending to give a more detailed description of approach 2, but I'll
> be away from the net for a week. Maybe when I get back.)
> 



More information about the e-lang mailing list