[cap-talk] Confused Deputies in Capability Systems

[David-Sarah Hopwood]

Karp, Alan H wrote:
> David-Sarah Hopwood wrote:
>>> 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.)
>>
> The attack is possible even with a correctly implemented TCB.  SAML
> certificates are assumed to be public documents.  Alice can include a
> copy of a delegation from Carol to Bob in a request Alice makes of Bob,
> and Bob may use Carol's permission on behalf of Alice. If Carol is the
> powerbox for the person running Bob, then we have a classic confused deputy.
> If not, it's a different form of confused deputy, but the result is that
> the attacker gains an authority.  Bob can protect himself by making sure
> the submitter of the request has the rights being delegated.  

I don't get it. How is it possible that any subject is able to rely on
the delegation from Carol to Bob, without Carol having been verified to
hold the delegated permissions by the capability system TCB (automatically,
without any explicit action on the part of Alice, Bob or Carol)? That
seems like a weakness that is not forced by the fact that certificates
are public. If the subjects were responsible for validating the certificates
themselves then it could result in this weakness, but presumably they are
not; the system is doing that.

-- 
David-Sarah Hopwood ⚥