[cap-talk] Confused Deputy, multiple authorities

Charles Landau clandau at macslab.com
Tue Oct 17 17:54:47 CDT 2006


At 2:15 PM -0700 10/17/06, Mark Miller wrote:
>Kragen makes other points about confused deputy problems on the web:
>http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html
>http://archive.cert.uni-stuttgart.de/archive/bugtraq/2000/05/msg00141.html

Whoa, now I'm confused.

The examples Kragen gives (which, unlike the Wikipedia article, are 
clear enough that even I can understand, not being well versed in web 
minutiae) are cases in which something acts with the *wrong* 
authority. To quote Kragen: "If Scooter had been able to express that 
it was just a nobody on the Web, not a DEC employee, it would not 
have accidentally downloaded these documents." And "In an ideal 
world, Jack's browser would send the canned request with
Mary's authority, not Jack's."

In these examples, it seems to me that simply using the correct 
identity would solve the problem. To me, the essence of the Confused 
Deputy is that there is no single identity that is right. To use 
Norm's compiler example (which, for reference, is at 
http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html), the compiler 
must use *both* its own authority to write the statistics file, and 
the client's authority to write the output file.

Kragen's examples do not seem well motivated, because there is 
nothing being done that necessarily requires multiple authorities. In 
the ClientSideTrojan example, there is no reason that the browser 
that executes Mary's Trojan request needs to be the same browser that 
remembers Jack's password. In the case of Scooter, I suppose it is 
possible that it does some other things that require its *.dec.com 
authority; I just don't know Scooter.

And while I'm criticizing Confused Deputy examples, the passwd 
example in http://en.wikipedia.org/wiki/Confused_Deputy is either 
poorly explained or not really a Confused Deputy example. Where are 
the multiple authorities? The passwd command isn't using any 
authority from the user.


More information about the cap-talk mailing list