[cap-talk] Confused Deputies in Capability Systems

[David-Sarah Hopwood]

Karp, Alan H wrote:
> Toby Murray wrote:
>> 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.).
>
> Validating capabilities passed as arguments does make sense, just not
> in an ocap system except when you're making a decision to use rights
> amplification.  Norm's original paper listed a number of reasons that
> input validation is difficult in the ACL case.  I wouldn't be surprised
> to learn that cap validation has a similar set of problems.
> 
> Validating capabilities does make sense in other environments.  Tyler
> pointed out a vulnerability in our Zebra Copy implementation.  In that
> work, capabilities are SAML authorization assertions.  Each service
> reference passed as an argument is represented by a SAML authorization
> assertion delegating to the service being invoked the right in the
> assertion.  We neglected to verify that the invoker had the right being
> delegated, which allowed a confused deputy attack.

This is not a confused deputy attack. It's a mistake in the implementation
of the capability system TCB. (It's also not a particularly subtle mistake,
since it directly violates a assertion of the system design.)

> You can't make that kind of mistake in an ocap system because the ability
> to designate the object is sufficient proof of the right to use it.

No, you could make a precisely analogous mistake in the *implementation* of
an ocap system.

-- 
David-Sarah Hopwood ⚥