[cap-talk] Toby's Confused deputy statement (was: Re: Confused deputies in hybrid systems)

[Karp, Alan H]

Shap wrote:
>
> I think this is closer to what we want, but I confess that it disturbs
> me. If this is right (and I think that it probably is, modulo further
> refinement), then it follows that the sealer/unseal operation pair
> renders a service potentially confusable.
>
When I first read this statement a few days ago, I quietly nodded in agreement.  On
further pondering, I don't think it fits the definition of the confused deputy.  Alice
has a sealed box.  Bob has the corresponding unsealer.  In order to exercise the
authority in the box, Bob must explicitly use the unsealer.  In other words, Bob is aware
that he is using an authority that he did not get from Alice.  He could make a mistake,
but that's not the same as being a confused deputy.

Consider the following Joe-E example, which I believe is closer, but still not exactly
the same as Norm's original example.  Java distinguishes methods by scope - public,
package, or private.  Say that Bob has a class O in his package that supports a package
scope write method and a public read method.  Bob provides a method, say compile, that
takes an argument of class O as the target for the compiler output.  Bob's program uses
an object of type O to hold log records.  Alice, who is not in Bob's package, has been
given a reference to the log object, enabling her to read it.  If Alice invokes Bob's
compile program and provides her reference to the log object, Bob will overwrite its
contents with the compiler output.

Perhaps it will be easier to understand in code snippets.  Modulo syntax errors, I
believe what I described above is

package Bob;
Class O { ... public String read(); void write(String s); }

Bob's compile program is

package Bob;
Class B {
        private O log = new O();
        ...
        public void compile(Source s, O output) {
                log.write("compiling");
                output.write(cc(s.read()); }
}

Alice's program is

package Alice;
Class A {
        ...
        bob.compile(source, log); }

Unlike the confused deputy with ambient authorities, this example has a clear error.  Bob
has combined a method with public scope with an argument having package scope.  The fix
is simple.  Bob should not use the same class for both the log and the target of the
output.  Nevertheless, I contend that such a vulnerability would be very hard to find.
It's root cause is the increased power the reference has when wielded by Bob instead of
Alice.  However, there is nothing in the syntax of the compile routine to indicate that
fact.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp