[cap-talk] Confused Deputy (definitions)

[Jed at Webstart]

I'm going to check my understanding of these definitions and their
binding to the issues we are considering below where ?!ng describes
how the situations correspond to our concerns.  After that check I'll
make some proposals below.

At 12:32 AM 10/25/2006, Ka-Ping Yee wrote:
>I've been reading the messages on this thread and thought perhaps
>it might be useful to describe the interpretations of the "confused
>deputy" concept i've seen here so far, as precisely as i can, and
>see if this helps us identify and name these distinct concepts.
>
>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).
>
>     Countermeasure:
>         Architectural change -- not a bug in D
>
>         1a. If the architecture allows, the problem can be fixed by
>             tightly binding an authenticator to each request.
>
>     Architectural Flaw:
>         Ambient authority
>         Identity-based access control
>
>
>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).
>
>     Countermeasure:
>         Architectural change -- not a bug in D
>
>         2a. If the architecture allows, D can query the system to
>             determine whether what U has named actually belongs to U
>             (but this can be tricky to do reliably).
>
>         2b. Otherwise, there is no possible way for D to make the
>             required distinction.  D cannot be fixed.
>
>     Architectural Flaw:
>         Separation of designation from authority
>
>
>3.  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, D fails to
>         implement these restrictions in an airtight way, and U can
>         exploit a flaw in D to cause D to misuse A (something the
>         provider of A didn't want).
>
>     Countermeasure:
>         Fix implementation vulnerability in D
>
>
>Situation 1 seems to fit "Cross-Site Request Forgery" fairly closely;

Let me see if I understand this fit, e.g. as per:

http://en.wikipedia.org/wiki/Cross-site_request_forgery

U is the remote site (Alice on the above page).  D is Bob's browser
where Bob has authenticated to his bank (e.g. with a cookie or
private key or a saved password).  Is that much right?  The part
that I'm having difficulty mapping is the idea that there's any
authentication of Alice and any issue with the persistence of any
such authentication.  As I understand the cross-site request forgery,
Alice simply provides a URL (e.g. appearing as an image) to get
Bob's browser to fetch that will try to exercise some authority that
Bob granted to his browser when he authenticated to his bank's
web site.  If that authority is successfully applied, a transfer can
be done from Bob's account at Alice's instigation without any
authentication of Alice at all.

However, I'm not sure my understanding above can be correct as
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.

As I understand the cross-site request forgery situation the basic
problem is that remote Web sites are allowed to direct a web
browser to URLs of their choosing (e.g. by redirection, whatever)
that can go through the http protocol in the context of an authenticated
Web "session" of the user executing the browser.

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?  Even then I can see how this sort
of attack might turn into something like a phishing attack.  How does
the user know the new authentication request isn't a continuation
of something they were doing with their "session"?  After all they
are going to be doing an awful lot of re authenticating in this case.

>Situation 2 seems to fit the classic Confused Deputy story fairly
>closely;

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!"

The "home files license" is something made available by it's own identity (it's
UID in Unix terminology) - D.  Access to what U names (the debug output in
Norm's description and the thing named A in ?!ng's discussion) should
be made available by U's identity.  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?
Of course it must be done properly, but at least architecturally the intent
(if not a completely adequate implementation) is there in Unix (Windows?).

>Situation 3 is my attempt to define what Jed described as
>"confusion" in the more general sense.

My intent was to include #1 or the cross-site request forgery (which seems a
bit different to me), #2, and #3 under the term "Confused Deputy".  That is,
whether D inappropriately used it's own authority rather than U's because:

1.  "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).
<I'm still not sure I understand this one>

or

1.5 (cross-site forgery) D is architected to allow remote requests to be
issued from D's authenticated environment,

or

2.  D has no way to specify that it wishes an action to be taken in the
context of the authorities of another user (Norm's Confused Deputy
in it's most limited sense),

or

3.  D does have the ability to distinguish actions authorized as itself
from those authorized as U but is somehow fooled (manipulate,
"confused") into taking an action using it's own authorization
on behalf of U that it's design didn't intend,

I believe all of the above can loosely be considered "Confused
Deputies".

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?

On the other hand, if we include all of the above within the
term "Confused Deputy" then I agree that it seems so general
as to have pretty much no meaning.

I'm not sure the best way out of this situation.  Updates to
the Wikipedia definitions await...  In the mean time should we
(I since I guess I'm the culprit) remove the linking between the
Confused Deputy and the Cross-site request forgery definitions?
I'm in favor of that approach.  If we can't even define what a capability
architecture is enough so that people can fail to understand it's
very simple idea after "much reading", then I think we have more
important areas to focus on.  We should get out of this "Confused
Deputy" morass and focus on that more basic and relevant issue.

I think perhaps the original "Confused Deputy" example in its pure
form is obscure enough and specific enough to an architecture that
no longer exists that it may not be appropriate to link it to more
current issues.  Do others feel that it has current relevance?  I certainly
don't want to seem to be tying the importance of the capability
approach to authorization to such an obscure problem that's not
significantly at issue in modern systems.

--Jed http://www.webstart.com/jed/