[cap-talk] Confused Deputy (definitions)

[Ka-Ping Yee]

Ka-Ping Yee wrote:
>1.  Situation:
>         At user U's request, entity D wields an authority A.  U does not
>         itself have A because A is too big; D has A and wields it in a
>         limited fashion upon authenticating U.  However, because the
>         security architecture only allows D to make a decision based on
>         U's identity, if U's authentication is persistent, D can be fooled
>         into misusing A for the wrong purpose (something U didn't want).

Jed at Webstart wrote:
> Let me see if I understand this fit, e.g. as per:
>
> http://en.wikipedia.org/wiki/Cross-site_request_forgery

The mapping between Situation 1 and Cross-Site Request Forgery
(as i had it in mind) goes like this:

    U <-> Bob
    D <-> Bob's bank
    A <-> the authority to change bank account balances

The bank validates the request to withdraw based on Bob's cookie,
which is a persistent authenticator -- not on Bob's authorization
of the specific request.

(You could say that both the browser and the bank are to blame for
the persistence of the cookie.  I hold the bank responsible here
because cookies are widely understood to be persistent tokens.)

> in the context of the above I don't see how this statement:
>
>          1a. If the architecture allows, the problem can be fixed by
>              tightly binding an authenticator to each request.
>
> makes sense.

Bob would not be vulnerable to CSRF if each withdrawal request is
required to come with a non-persistent authenticator.

> By "tightly binding an authenticator to each request" do you mean
> that a user would have to do something like type in a password or
> pin with every request they make?

That would be one way (but a rather inconvenient one).  Another way
would be to include a hidden field with a session key on the form
that Bob submits, or to incorporate a session key into the URL,
so that Alice cannot forge the form submission.

Ka-Ping Yee wrote:
>2.  Situation:
>         At user U's request, entity D wields an authority A.  U does not
>         itself have A because A is too big; D has A and wields it in a
>         limited fashion upon authenticating U.  U's request also names
>         something belonging to U that D is supposed to use (in a
>         different way than it uses A).  By naming A instead, U can fool
>         D into misusing A (something the provider of A didn't want).

Jed at Webstart wrote:
> The key to the Confused Deputy problem as Norm describes it:
>
> http://www.cap-lore.com/CapTheory/ConfusedDeputy.html
>
> seems to me to be,
> "When it produces statistics it intends to use the authority
> granted by its home files license. When it produces its debugging output it
> intends to use authority from its invoker. The compiler had no way of
> expressing these intents!"

Here's the mapping i had in mind for Situation 2.

    U <-> the compiler user
    D <-> the compiler
    A <-> write access to (SYSX)BILL

The user isn't supposed to have direct access to (SYSX)BILL, but
by naming (SYSX)BILL in the request, the user can cause the compiler
to misuse its authority to write to (SYSX)BILL (i.e. to overwrite the
file with debugging information instead of billing information).

> If D can access "A" with U's authority
> for the purposes of the request by U (as many have discussed in the
> case of Unix), then isn't this limited "Confused Deputy" problem solved?

That's what 2a is about.

> If we only want the "Confused Deputy" term to apply to #2, then
> I think it looses almost all meaning.  I don't think that even Unix
> (or Windows?) have such a weak authorization system that this
> architectural problem is manifest.  Perhaps it's part of the problem
> seen in efforts at non-root SUID programming?

I don't think so -- i believe the original definition of "confused
deputy" is still relevant, even if it is narrower than what i had
originally thought.  The key property of the confused deputy problem
is that it is a flaw in the security architecture, not a bug in the
deputy (by "bug" i mean "the implementation doesn't match the design").


-- ?!ng