<html>
<body>
cap-talk,<br><br>
I hope I'm not the only one who's unhappy with the way this thread
apparently<br>
ended. Although I don't have as much time for cap-talk recently,
I've read<br>
through this thread - I believe with understanding - and I believe I
can<br>
add some clarity.<br><br>
These two statements to me suggest that there is still a fundamental
confusion<br>
lurking somewhere:<br><br>
At 04:07 PM 2/12/2009, Marcus Brinkmann wrote:<br>
<blockquote type=cite class=cite cite="">...<br><br>
I wrote my mail before I read and understood the explanations of what
others<br>
mean by a confused deputy. If you take the following two
statements:<br><br>
1. A confused deputy situation arises if a designation is passed
between<br>
principles and changes associated authority in transit.<br><br>
2. A capability system always combines designation and
authorization.<br><br>
Then I concede that it follows logically that a confused deputy situation
can<br>
never arise in such capability systems. However, this just defines
the<br>
problem away. The real question is if we can avoid using other
designations<br>
beside capabilities in system design. I think the answer to that is
no, we<br>
can not avoid that. Seems pretty obvious to me, given that
capabilities are<br>
not universal in the sense that raw data is.</blockquote><br>
and<br><br>
At 04:29 PM 2/12/2009, Marcus Brinkmann wrote:<br>
<blockquote type=cite class=cite cite="">...<br><br>
It is possible that I have never understood what a confused deputy
problem is.<br>
Apparently, the examples I (and Toby) are thinking of are just
programming<br>
errors in capability systems. But apparently at the same time, the
"billing<br>
compiler" example from the 1960s or so is not just a programming
error. As my<br>
experience with Unix only dates back to the early 90s, when SUID and
access()<br>
were already established programming paradigms (along with others such
as<br>
input validation in scripting), I can not associate with the billing
compiler<br>
example. It seems to me as much a programming error to me as the
other<br>
non-confused-deputy examples.<br><br>
In my day to day practice as a programmer, I sometimes use capabilities
(file<br>
descriptors, HANDLEs), and sometimes I use files or named pipes, or
even<br>
network sockets for communication. I choose whatever is most
appropriate for<br>
any given situation, based on a series of concerns, but _none of
these<br>
concerns is security_, because they all can be made sufficiently secure,
and<br>
there is no magic to any of it.</blockquote><br>
I believe (though I'm not sure) I know what that confusion is.<br><br>
When Marcus says:<br><br>
<blockquote type=cite class=cite cite="">If you take the following two
statements:<br><br>
1. A confused deputy situation arises if a designation is passed
between<br>
principles and changes associated authority in transit.<br><br>
2. A capability system always combines designation and
authorization.<br><br>
Then I concede that it follows logically that a confused deputy situation
can<br>
never arise in such capability systems.</blockquote><br>
I agree. I hope we all do. However, when he says:<br><br>
<blockquote type=cite class=cite cite="">However, this just defines the
problem away.</blockquote><br>
I don't agree. I believe it (the capability communication model)
does<br>
much more than "just define the problem away". It
provides an approach<br>
to communication that avoids this particular sort of security problem
-<br>
the "Confused Deputy" problem as defined on:<br><br>
<a href="http://en.wikipedia.org/wiki/Confused_deputy_problem" eudora="autourl">
http://en.wikipedia.org/wiki/Confused_deputy_problem<br><br>
</a>Marcus says:<br>
<blockquote type=cite class=cite cite="">The real question is if we can
avoid using other designations<br>
beside capabilities in system design. I think the answer to that is
no, we<br>
can not avoid that. Seems pretty obvious to me, given that
capabilities are<br>
not universal in the sense that raw data is.</blockquote><br>
While we may not be able to or want to avoid using other
designations<br>
besides capabilities in system design, we manifestly can avoid<br>
using any other such designations <b>for communicating
authority</b>.<br>
This is exactly what the capability model of communication
provides.<br><br>
When two principles (domains, mutually suspicious processes)<br>
communicate within the capability model, they can communicate<br>
data and capabilities. A key factor in the communication of<br>
the capabilities is that neither side of the communication<br>
trusts the other side with specifying the designations for<br>
the communicated (or any other) capabilities.<br><br>
In a typical c-list communication scheme, for example, with<br>
Alice sending Bob some data and a capability, Alice designates<br>
a c-list index in her c-list for the capability to send and<br>
Bob designates an index in his c-list for the capability to<br>
be received. With such an approach it's clear that Bob
shouldn't<br>
trust Alice to specify an index in Bob's c-list.<br><br>
Alice's
c-list
Bob's c-list<br><br>
i: Sent
capability
j: Received capability<br><br>
Alice designates i, Bob designates j, the communication system<br>
copies the capability from the i index in Alice's c-list to the<br>
j index in Bob's c-list.<br><br>
Even with capabilities as data, the sender and receiver are<br>
clear on the source of any authority as capabilities (Alice<br>
only sent capabilities that are received by Bob in the<br>
message from Alice - as data).<br><br>
<br>
Marcus is uncomfortable with Norm's original compiler billing
example<br>
of a Confused Deputy. Let's then take a modern example and see<br>
how the capability communication model eliminates the possibility<br>
of the Confused Deputy problem. Again from:<br><br>
<a href="http://en.wikipedia.org/wiki/Confused_deputy_problem" eudora="autourl">
http://en.wikipedia.org/wiki/Confused_deputy_problem</a><br><br>
we can consider the "cross-site request forgery
(CSRF)":<br><br>
<a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" eudora="autourl">
http://en.wikipedia.org/wiki/Cross-site_request_forgery</a><br><br>
problem. I hope we all agree that this is an example of a<br>
Confused Deputy security vulnerability/attack. Using the
example<br>
that they give there:<br><br>
<img
src="http://bank.example/withdraw?account=bob&amount=1000000&for=mallory"><br>
<br>
we see that a sender, let's say a process controlled by Mallory,<br>
sends data (including the above html) to another process, a Web<br>
browser controlled by Bob. In that message Mallory sends over<br>
some designations of accounts, "bob" and
"mallory". In the<br>
context of the communication between Bob and the Bank these<br>
names designate authorities - authorities that are enabled<br>
by the cookie or some other aspect (e.g. previous authentication<br>
of a statefull communication channel) of the communication, but<br>
that are communicated as data designators. The "bob"
designation<br>
specifies full authority over Bob's account and the
"mallory"<br>
designation specifies some public (e.g. deposit only) authority<br>
to the Mallory account.<br><br>
Bob's browser receives this URL and innocently invokes the<br>
"get" method on the URL (in the act of fetching an image).<br>
The effect is to move money from Bob's account to Mallory's<br>
account - very much against the wishes of Bob.<br><br>
I believe the problem is in the model of the communication.
The<br>
communication between Bob and the Bank is using local data<br>
designations to refer to authorities.<br><br>
With a capability communication model this problem cannot arise.<br>
In the capability communication model Bob would send the bank<br>
two capabilities, one to Bob's full authority account capability<br>
and one to Mallory's deposit-only account capability. The<br>
capability model could be through c-lists (e.g. as above with<br>
the Alice to Bob communication) or even a capabilities as<br>
data model (e.g. YURLs or Web keys). In both cases (any valid<br>
capability model of communication) the communication from<br>
Mallory to Bob can only contain capabilities that Mallory<br>
possessed. The strings "bob" and/or "mallory"
would be treated<br>
just as any other data. Bob's browser may well have access to<br>
an account capability for Bob's account with full authority.<br>
However, we see clearly in the capability model of communication<br>
that there is no "confusion" possible in Bob's browser
between<br>
the string "bob" communicated from mallory and Bob's
account<br>
capability.<br><br>
Note that even if the communication between Bob and the Bank<br>
was ongoing on a channel on which Bob initially sent over<br>
Bob's account capability, in a capability communication scheme<br>
it would be clear to Bob's browser that communication over<br>
that channel shouldn't include data from untrusted sources.<br><br>
I hope all of the above is clear. To me it seems clear that<br>
a capability model of communication does much more than "just<br>
define away the problem (Confused Deputy)". It provides a<br>
communication model in which the Confused Deputy problem can't<br>
arise - as Marcus noted in #1 and #2 - though as I suggest here,<br>
this is more than just a matter of definition.<br><br>
If others (e.g. Marcus or Toby or ...?) believe that the<br>
capability communication model only contributes to avoiding<br>
Confused Deputies by defining the problem away, then perhaps<br>
they can suggest how something like the "cross-site request<br>
forgery (CSRF)" could arise within the context of capability<br>
communication.<br><br>
<br>
On a related topic, in doing some research for this message<br>
I looked a bit at the description of "clickjacking":<br><br>
<a href="http://en.wikipedia.org/wiki/Clickjacking" eudora="autourl">
http://en.wikipedia.org/wiki/Clickjacking</a><br><br>
which is also referred to on:<br><br>
<a href="http://en.wikipedia.org/wiki/Confused_deputy_problem" eudora="autourl">
http://en.wikipedia.org/wiki/Confused_deputy_problem</a><br><br>
where it says the clickjacking category "can be analysed as
confused<br>
deputy attacks". I don't agree with this statement. I
believe<br>
something else is going on with "clickjacking" where the
user<br>
is being fooled into executing code supplied by a malicious<br>
user due to the nature of an interface.<br><br>
I believe the statement that clickjacking is a form of Confused<br>
Deputy attack should be removed from the Confused Deputy<br>
page. Others?<br><br>
Apologies for the tome.<br>
<x-sigsep><p></x-sigsep>
--Jed
<a href="http://www.webstart.com/jed-signature.html" eudora="autourl">
http://www.webstart.com/jed-signature.html</a></body>
</html>