[cap-talk] Confused Deputies in Capability Systems

[Karp, Alan H]

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.

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.  SAML assertions are assumed to be public documents, which anyone can copy.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp