[cap-talk] Confused Deputies in Capability Systems

[Fred Spiessens]

Hi Toby,

> G'day,
>
> Following the recent discussion of confused deputies in the context of
> Tyler's "ACLs Don't" paper, I wanted to talk a bit more about these in
> the context of object-capability systems.
>
> A confused deputy is any program that can be confused into using  
> part of
> its authority, given to it for one purpose, for a different purpose,
> usually on behalf of some (malicious) client. A general symptom of a
> confused deputy is that the malicious client has excess authority.
>
> I'd like to try the unconventional argument that confused deputies  
> could
> be common-place even in object-capability systems that we  
> traditionally
> believe make them much harder to construct. This argument is  
> premised on
> the (common, especially by non-capability folks) observation that the
> prototypical confused deputy attack in the ACL model arises because  
> the
> Compiler does not perform input validation (by checking that the  
> string
> that the User passes it does not designate its billing file).
>
> My argument is that confused deputies can arise whenever a service  
> in an
> object-capability system similarly fails to perform input validation  
> on
> the capabilities it is passed (rather than arbitrary strings), in the
> case that those capabilities are more powerful in its hands than in
> those of its clients (e.g. via rights-amplification).
>
> The only means of protecting itself against such attacks is for the
> service to perform input validation on capabilities it is passed --  
> this
> is why object-cap systems include capability-authentication mechanisms
> primitively (e.g. trademarks in E, Cajita, KeyKOS and EROS, static
> checking of final types in Joe-E etc.).
>
> Are there other ways to defend against these capability-based confused
> deputy attacks? If not, then the argument that the most appropriate  
> way
> to deal with them in IBAC systems is through input validation (rather
> than transforming these systems to object-capability systems) seems  
> more
> understandable.
>
> Cheers
>
> Toby

I do think input checking is necessary indeed to avoid the capability- 
based confused deputy attack. However, in capabilities the result of  
the check does not have to be simply "accept" or "reject", but could  
also be "accept-but-use-with-caution".

You do talk about "input validation" in the sense of answering the  
question: "can the input cause my authority to be amplified in a way I  
don't want?", right?

Then consider what would happen if the answer is "yes" in a capability  
system: the deputy might still decide to accept the input because he  
has a lot more control about which capabilities he uses for what  
purposes, and he may be able to avoid the wrong type of amplification  
if he knows what type of danger-for-amplification the input  
presents.   IBAC systems with perfect input validation would simply  
have to reject the input, I assume.

cheers,

Fred.