[cap-talk] Confused Deputies in Capability Systems

[Toby Murray]

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