Confused Deputy

Wiki
1

Note that in this (SYSX)BILL case, the root of the problem is who the program is acting as. This is the underlying cause of all confused deputies, from the perspective of auth system design.

The program receives the file name from the user, but does not know whether the user had permission to write the file. When the program opens the file, the system uses the program’s permission, not the user’s. When the file name was passed from the user to the program, the permission did not go along with it; the permission was increased by the system silently and automatically.

It is not essential to the attack that the billing file be designated by a name represented as a string. The essential points are that:

  • the designator for the file does not carry the full authority needed to access the file;
  • the program’s own permission to access the file is used implicitly.

Capabilities are meant to remove this problem

A few years ago, Christine found an edge case in ocap that, depending on the exact semantics of rights amplification, may have a confused deputy

I believe that we have the correct semantics for that case in ucan, but am going to triple check

2

Ah. So e.g. the classic symlink vulnerability is an example for a confused deputy, correct?
The one where you have a file server and you’re storing a symlink in the directory you have access to, but which actually symlinks to something that’s higher up the hierarchy. So when you ask the server to resolve your symlink, the server does that with its own permissions, thus implicitly giving you read access to outside your own subtree.