[cap-talk] Confused Deputy (definitions)

[Jed at Webstart]

At 05:33 PM 10/25/2006, Ka-Ping Yee wrote:
>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

I see.  This contrasts with what I was assuming:

U <-> Alice   <the remote Web site where the threat comes from>
D <-> Bob's browser  <who is being confused into acting inappropriately
                                 on Alice's behalf rather than on 
Bob's but with
                                 Bob's authority>, and
A <-> the authority to change bank account balances  <as you have>

Somehow it seems to me that for the Cross-site Request Forgery
you have to get Alice into the equation as it's Alice that is obtaining
an inappropriate form of access.

>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.

Let me restate this in another way to see if I'm understanding it
<this seems like one of those discussions that would be much better
in person>

The bank authenticates Bob and then ties that authentication to
the cookie.  This problem even exists with repeated password
remembered by the browser or with a personal certificate whose
private key was pulled out by the browser in response to Bob's pin
and then used to do a handshake for a shared secret that persists.
Whatever the case, for the duration of the browser session, the
Bank assumes that the contacts from this browser process are
acting with Bob's authority.

In my view Alice is "merely" hijacking ('confusing'?) the browser
to inappropriately act with Bob's authority.

>(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.)

As noted above, I don't believe this problem is limited to the
use of cookies.  I believe it is just as serious if the authentication
is done with a simple password (cached by the browser) or
with a personal certificate (where the shared secret is cached
by the browser - I'm not so sure about the details of this one).

What do you think the Bank can do?  I consider this a problem
with the browser.  The browser was authorized by Bob to act
on Bob's behalf (through whatever authentication means) but then
allowed Alice to hijack the browser process for her own
nefarious purposes.

> > 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.

My interpretation of the above is that you seem to be suggesting that
Bob's browser should remain stateless between transactions and
authenticate each transaction.  I don't think this is practical.  To me
it seems clear that at some point Bob's browser must be given the
authority to act on Bob's behalf (at least with some of Bob's permissions
in a POLA world).  You seem to be arguing that this should only
happen for a single request (RPC?)?  That doesn't seem to me to
be getting at the essence of this problem.  Perhaps that's why I
consider it closer to the "Confused Deputy" situation in that I see
the browser acting with Bob's authority without being able to instead
use Alice's authority for the URL that came in from Alice.

> > 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.

Hmmm.   This last approach still strikes me as rather perilous given that
Alice is calling the shots on where the browser should be directed and
the browser is still storing information sufficient to act as Bob, but I
admit that I can't immediately see an opportunity for an exploit in that
approach (which I consider something of a hack - though I give "hacks"
high honors if they solve real problems).

>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).

We're thinking along the same lines there.

> > 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.

I understand.  However, in the case of Unix it seems that there is such
a means (though awkward as some say).  From the viewpoint of a Unix
programmer/user this problem has been known about and dealt with
adequately for years.  Why do we need capabilities?  The problem
that Norm describes as the "Confused Deputy" problem simply doesn't
exist in Unix, despite Norm claiming that, "Our operating system was
much like Unix...":

http://www.cap-lore.com/CapTheory/ConfusedDeputy.html

Unix (and ambient authority) defenders will simply argue that
Norm's operating system got it wrong and that Unix got it
right - end of problem.  No fancy "capabilities" needed.

> > 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").

Then what is the flaw in the security architecture of market leading
operating systems like Unix and Windows that leads to "Confused
Deputy" exploits?

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