[cap-talk] Confused Deputies in Capability Systems

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> Sandro Magi wrote:
>> I was thinking of a sort of trusted object which performs the check at
>> the appropriate time. In C#:
>>
>> public sealed class VettedPath
>> {
>>   string path;
>>
>>   // no way to construct an instance
>>   VettedPath () {}
>>
>>   // implicit coercion of a string to a VettedPath
>>   // that performs the access check at time of creation
>>   public static implicit operator VettedPath(string path)
>>   {
>>     // access check, throws UnauthorizedException
>>     File.AccessCheck(path);
> 
> I'm assuming this check is based on the identity of the direct
> caller of 'operator VettedPath(string)'.
> 
> (If it is based also on indirect callers, then we have a stack
> inspection system: see that section of Tyler's "ACLs Don't" paper
> for general problems with such systems, and see the recent
> Java Calendar exploit for a concrete example.)
> 
>>     return new VettedPath(path);
>>   }
>> }
> 
> The problem is that there is no "appropriate time" to perform an
> identity-based access check. We have only succeeded in moving the
> point at which the confused deputy vulnerability is present to the
> code that triggers the access check. That is, the direct caller
> of 'operator VettedPath(string)' is now the confusable deputy.

I should also have mentioned that making the check triggered by
an implicit conversion, as the above code does, is a particularly
bad idea.

-- 
David-Sarah Hopwood ⚥