[cap-talk] Confused Deputies in Capability Systems - not

Jed Donnelley capability at webstart.com
Mon Feb 23 06:36:48 EST 2009


cap-talk,

I hope I'm not the only one who's unhappy with the way this thread apparently
ended.  Although I don't have as much time for cap-talk recently, I've read
through this thread - I believe with understanding - and I believe I can
add some clarity.

These two statements to me suggest that there is still a fundamental confusion
lurking somewhere:

At 04:07 PM 2/12/2009, Marcus Brinkmann wrote:
>...
>
>I wrote my mail before I read and understood the explanations of what others
>mean by a confused deputy.  If you take the following two statements:
>
>1. A confused deputy situation arises if a designation is passed between
>principles and changes associated authority in transit.
>
>2. A capability system always combines designation and authorization.
>
>Then I concede that it follows logically that a confused deputy situation can
>never arise in such capability systems.  However, this just defines the
>problem away.  The real question is if we can avoid using other designations
>beside capabilities in system design.  I think the answer to that is no, we
>can not avoid that.  Seems pretty obvious to me, given that capabilities are
>not universal in the sense that raw data is.

and

At 04:29 PM 2/12/2009, Marcus Brinkmann wrote:
>...
>
>It is possible that I have never understood what a confused deputy problem is.
>  Apparently, the examples I (and Toby) are thinking of are just programming
>errors in capability systems.  But apparently at the same time, the "billing
>compiler" example from the 1960s or so is not just a programming error.  As my
>experience with Unix only dates back to the early 90s, when SUID and access()
>were already established programming paradigms (along with others such as
>input validation in scripting), I can not associate with the billing compiler
>example.  It seems to me as much a programming error to me as the other
>non-confused-deputy examples.
>
>In my day to day practice as a programmer, I sometimes use capabilities (file
>descriptors, HANDLEs), and sometimes I use files or named pipes, or even
>network sockets for communication.  I choose whatever is most appropriate for
>any given situation, based on a series of concerns, but _none of these
>concerns is security_, because they all can be made sufficiently secure, and
>there is no magic to any of it.

I believe (though I'm not sure) I know what that confusion is.

When Marcus says:

>If you take the following two statements:
>
>1. A confused deputy situation arises if a designation is passed between
>principles and changes associated authority in transit.
>
>2. A capability system always combines designation and authorization.
>
>Then I concede that it follows logically that a confused deputy situation can
>never arise in such capability systems.

I agree.  I hope we all do.  However, when he says:

>However, this just defines the problem away.

I don't agree.  I believe it (the capability communication model) does
much more than "just define the problem away".  It provides an approach
to communication that avoids this particular sort of security problem -
the "Confused Deputy" problem as defined on:

http://en.wikipedia.org/wiki/Confused_deputy_problem

Marcus says:
>The real question is if we can avoid using other designations
>beside capabilities in system design.  I think the answer to that is no, we
>can not avoid that.  Seems pretty obvious to me, given that capabilities are
>not universal in the sense that raw data is.

While we may not be able to or want to avoid using other designations
besides capabilities in system design, we manifestly can avoid
using any other such designations for communicating authority.
This is exactly what the capability model of communication provides.

When two principles (domains, mutually suspicious processes)
communicate within the capability model, they can communicate
data and capabilities.  A key factor in the communication of
the capabilities is that neither side of the communication
trusts the other side with specifying the designations for
the communicated (or any other) capabilities.

In a typical c-list communication scheme, for example, with
Alice sending Bob some data and a capability, Alice designates
a c-list index in her c-list for the capability to send and
Bob designates an index in his c-list for the capability to
be received.  With such an approach it's clear that Bob shouldn't
trust Alice to specify an index in Bob's c-list.

      Alice's c-list             Bob's c-list

i:  Sent capability            j: Received capability

Alice designates i, Bob designates j, the communication system
copies the capability from the i index in Alice's c-list to the
j index in Bob's c-list.

Even with capabilities as data, the sender and receiver are
clear on the source of any authority as capabilities (Alice
only sent capabilities that are received by Bob in the
message from Alice - as data).


Marcus is uncomfortable with Norm's original compiler billing example
of a Confused Deputy.  Let's then take a modern example and see
how the capability communication model eliminates the possibility
of the Confused Deputy problem.  Again from:

http://en.wikipedia.org/wiki/Confused_deputy_problem

we can consider the "cross-site request forgery (CSRF)":

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

problem.  I hope we all agree that this is an example of a
Confused Deputy security vulnerability/attack.  Using the example
that they give there:

<img src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory">

we see that a sender, let's say a process controlled by Mallory,
sends data (including the above html) to another process, a Web
browser controlled by Bob.  In that message Mallory sends over
some designations of accounts, "bob" and "mallory".  In the
context of the communication between Bob and the Bank these
names designate authorities - authorities that are enabled
by the cookie or some other aspect (e.g. previous authentication
of a statefull communication channel) of the communication, but
that are communicated as data designators.  The "bob" designation
specifies full authority over Bob's account and the "mallory"
designation specifies some public (e.g. deposit only) authority
to the Mallory account.

Bob's browser receives this URL and innocently invokes the
"get" method on the URL (in the act of fetching an image).
The effect is to move money from Bob's account to Mallory's
account - very much against the wishes of Bob.

I believe the problem is in the model of the communication.  The
communication between Bob and the Bank is using local data
designations to refer to authorities.

With a capability communication model this problem cannot arise.
In the capability communication model Bob would send the bank
two capabilities, one to Bob's full authority account capability
and one to Mallory's deposit-only account capability.  The
capability model could be through c-lists (e.g. as above with
the Alice to Bob communication) or even a capabilities as
data model (e.g. YURLs or Web keys).  In both cases (any valid
capability model of communication) the communication from
Mallory to Bob can only contain capabilities that Mallory
possessed.  The strings "bob" and/or "mallory" would be treated
just as any other data.  Bob's browser may well have access to
an account capability for Bob's account with full authority.
However, we see clearly in the capability model of communication
that there is no "confusion" possible in Bob's browser between
the string "bob" communicated from mallory and Bob's account
capability.

Note that even if the communication between Bob and the Bank
was ongoing on a channel on which Bob initially sent over
Bob's account capability, in a capability communication scheme
it would be clear to Bob's browser that communication over
that channel shouldn't include data from untrusted sources.

I hope all of the above is clear.  To me it seems clear that
a capability model of communication does much more than "just
define away the problem (Confused Deputy)".  It provides a
communication model in which the Confused Deputy problem can't
arise - as Marcus noted in #1 and #2 - though as I suggest here,
this is more than just a matter of definition.

If others (e.g. Marcus or Toby or ...?) believe that the
capability communication model only contributes to avoiding
Confused Deputies by defining the problem away, then perhaps
they can suggest how something like the "cross-site request
forgery (CSRF)" could arise within the context of capability
communication.


On a related topic, in doing some research for this message
I looked a bit at the description of "clickjacking":

http://en.wikipedia.org/wiki/Clickjacking

which is also referred to on:

http://en.wikipedia.org/wiki/Confused_deputy_problem

where it says the clickjacking category "can be analysed as confused
deputy attacks".  I don't agree with this statement.  I believe
something else is going on with "clickjacking" where the user
is being fooled into executing code supplied by a malicious
user due to the nature of an interface.

I believe the statement that clickjacking is a form of Confused
Deputy attack should be removed from the Confused Deputy
page.  Others?

Apologies for the tome.

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090223/16184ca5/attachment-0001.html 


More information about the cap-talk mailing list