[cap-talk] Confused Deputy, multiple authorities - Norm?

[Jed at Webstart]

Regarding:

At 08:57 AM 10/20/2006, Charles Landau wrote:
>At 6:52 PM -0700 10/19/06, Jed at Webstart wrote:
> >At 03:54 PM 10/17/2006, Charles Landau wrote:
> >  >And while I'm criticizing Confused Deputy examples, the passwd
> >>example in http://en.wikipedia.org/wiki/Confused_Deputy is either
> >>poorly explained or not really a Confused Deputy example. Where are
> >>the multiple authorities? The passwd command isn't using any
> >>authority from the user.
> >
> >which I didn't write, but I also didn't correct as I believe I understood
> >the sense of "confused" deputy.  The authority of the deputy in
> >the case of passwd is root - an authority that can change any
> >password (and much more) in, for example, the /etc/passwd file.
> >The authority of the user making the passwd request is whatever
> >their UID is that the passwd command can determine by that
> >hack "original UID" mechanism or whatever it is that Unix
> >calls it.

and:

>At 10:49 AM 10/20/2006, Sandro Magi wrote:
>Jed at Webstart wrote:
> >> ...
> > ...I believe I understood the sense of "confused" deputy...
>
>I think Charlie is correct. Since passwd runs only with root authority,
>the user's authority never enters the picture. As long as the user is
>permitted to run the passwd command (dictated by the permissions on the
>passwd executable), root authority then takes over. Multiple (disjoint)
>authorities are never handled simultaneously and the program cannot
>become confused. "root" authority is not even necessary; even if
>passwords were managed by some unprivileged user, the confused deputy
>cannot occur in this instance.
>
>The UID is just a number. Passwd isn't using any of the user's
>authority to, say, write the user's files.
>
>Furthermore, the root authority is a superset of the user's
>authority, so passwd doesn't need any authority from the user. It
>just needs to be careful using the authority it has.
>
>In the above, I'm using "authority" to mean authority that is known
>to and enforced by the operating system. Passwd implements a new
>authority; anyone who can cause the "original UID" to be set to X can
>change the password file entry for X. It is straightforward for
>passwd to implement this correctly.

I believe we have exactly the same understanding of the passwd
example.  I don't see any technical issues there.

At 08:57 AM 10/20/2006, Charles Landau wrote:
>Here is one way to see the difference between passwd and Norm's
>compiler example. The compiler cannot protect its statistics file,
>without resorting to checking that the name of the output file
>provided by the user is different from the name of the statistics
>file.

That is system dependent.  If the compiler could check the users
UID (as in the Unix case) then the compiler could solve the Confused
Deputy problem in so far as that ambient authority model goes.
Specifically regarding (from:
http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html ):

"The billing information file (SYSX)BILL was also stored in SYSX. 
Some user came to know the name (SYSX)BILL and supplied it to the 
compiler as the name of the file to receive the debugging 
information. The compiler passed the name to the operating system in 
a request to open that file for output. The operating system, 
observing that the compiler had home files license, let the compiler 
write debugging information over (SYSX)BILL. The billing information was lost."

If the compiler could know the users UID it could check to insure 
that the user had write access to their debugging information file.

>Even that may not work; what if the name is a link or symbolic
>link? (Norm: what was the actual resolution of this problem?) Passwd,
>on the other hand, just needs to take the "original UID" and change
>that entry. How can passwd be "confused"?

With parameters that confuse it (e.g. command lines too long), buffer 
overflows of any sort, etc., etc.  I'm surprised you ask that 
question.  If the passwd command can be induced to change a password 
other than the user's, then the passwd command has been 
"confused".  I believe there have been just such instances of 
confusion in the passwd in the past, though I don't have an example 
at hand.  Such confusion is certainly possible.

Consider the now fairly well known problem with the password checking 
routine in Tenex.  All it did was to read the valid passwords and 
compare them with an argument that was passed in.  The fact that this 
was done byte by byte and the bytes could be put at the boundary of a 
memory segment was enough to "Confuse" that deputy into revealing all 
the passwords on the system in n x m time vs. n ** m time which of 
course made the system completely insecure in that case.

The "confusion" of a deputy can be subtle.

On the other hand, I think there is a distinction that can be 
made.  In Norm's original example there was no way for the compiler 
to get the information it needed about whether or not it's client had 
access to the file it was writing into.   This was an impossible 
situation.  Norm argues that the solution requires capabilities.

In the case of Unix with SUID I believe the problem is more 
subtle.  In the Unix case an SUID application can get the original 
UID of the user and to a large extent can determine if an action 
would be beyond the authority of a user.  I believe one can construct 
a case on Unix where the same impossible situation arises.  For 
example where the UID of the service (e.g. an SUID compiler) doesn't 
have read (x) access to a directory in which there is a file that 
it's UID has write access to but the user's UID does not.  I haven't 
thought about this much and would like to hear from others, but I 
believe such a narrow example would be in keeping with the narrowest 
interpretation of the Confused Deputy notion.

Situations where no "original 'UID'" is available of course 
abound.  The typical network service situation is just such - e.g. an 
sshd, a slapd, an Oracle listener, etc., etc.  There the "user" 
(whatever process is at the other end) must be assumed to have only a 
default (no?) authority when any connection originally 
happens.  Anything that the client asks for will naturally be 
validated by whatever means the "Deputy" in such a case has available 
- generally only what comes through the network connection.  Even at 
that of course "confusion" of such Deputies (e.g. buffer overflows, 
etc.) are common.

We could ask whether the term "Confused Deputy" should be limited to 
the case where the Deputy has no way to determine what the 
appropriate authorization for the client is or whether the "Confused 
Deputy" should apply to the more general case.  I believe the 
Wikipedia article is using it in the broader sense.  In that sense I 
believe the article is reasonably well stated, though of course it 
could be expanded and provide additional clarification.

Perhaps we should hear from Norm about whether he'd prefer the term 
he coined to be used in his original narrow sense on in the more 
general sense used in the Wikipedia article?

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