[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