[cap-talk] Is this attack feasible in any real ocap systems?

[Bill Frantz]

toby.murray at comlab.ox.ac.uk (Toby Murray) on Friday, March 28, 2008 wrote:

>I've been working recently on modelling ocap patterns in CSP. I've found
>a potential attack on the Stiegler sealer-unsealer implementation, but
>it exists only in ocap systems with the following properties:
>
>  1. when A sends a message to B, B is given a "use once" capability,
>ba, to be used for sending back the reply
>  2. B can call ab during  a later invocation to return back to A.
>  3. The system is single-threaded (which is required or else thee
>sealer-unsealer implementation is easily broken)
>
>Property 2 rules out E, since a method's ejector is disabled once that
>method invokes any ejector (I think.)
>
>The attack works as follows. Alice holds an unsealer. Bob holds the
>corresponding box. Alice can obtain the contents of the box without
>having to possess it, nor a capability to Bob. There is some other
>object that is invoking both Alice and Bob. Call it Thread.
>
>1. Thread invokes Alice and she acquires use-once return capability, c1
>2. Alice calls unsealer.unseal(Alice)
>3. Unsealer calls Alice.divulge(), she acquires return cap, c2
>4. Alice invokes c1, thereby giving control back to Thread
>5. Thread invokes Bob.
>6. Bob calls box.divulge(), box puts contents into channel reachable by
>the unsealer, Bob returns back to Thread
>7. Thread invokes Alice.
>8. Alice calls c2, to return back to the Unsealer that called her in
>step 3
>9. Unsealer checks channel, finds contents inside and returns it back to
>Alice that called it in Step 2
>10. Alice gets contents of box.
>
>My question is: does anyone know of any cap systems that embody these
>semantics? i.e. any systems in which this attack is viable? 

It seems on the surface that the KeyKOS et.al. group of systems
meet the basic requirements 1-2 above, and are single threaded
within a single object, so they may meet requirement 3 as well.

Let my try to translate the attack to an implementation in these
systems:

1. Alice is CALLed by a domain of thread (leaving that domain busy,
with Alice holding a resume key (c1) to that domain).

2. Alice starts a helper (Alice-helper) by returning to it (so
Alice becomes ready). The helper CALLs the unsealer domain passing
Alice as the box.

3. The unsealer CALLs Alice, thinking she is a box, and Alice saves
the resume key (c2) to the unsealer.

4. Alice RETURNs to c1, allowing Thread to resume execution.

5. Thread CALLs Bob.

6. Bob calls box(divulge ==>...) [note that box and unsealer must
be different domains otherwise Bob would block on the busy domain.
This requirement may violate requirement 3.] Box puts its contents
into a location shared with unsealer. and RETURNs to Thread

7. Thread CALLS Alice.

8. Alice RETURNs to c2, causing the unsealer to resume execution.

9. The unsealer finds something in the shared location (channel),
and RETURNs it to Alice-helper

10. Alice_helper gets the contents of box, which it shares with
Alice.


Toby's sample code:

>def makeSealerUnsealer(){
>   def nothing {}
>   var channel := nothing
>
>   def sealer{
>      to seal(contents){
>         def box{
>            to divulge(){
>               channel := contents
>            }
>         }
>         return box
>      }
>   }
>
>   def unsealer{
>      to unseal(box){
>         channel := nothing
>         println("unsealer: calling box.divulge()")
>         box.divulge()
>         println("unsealer: box.divulge() returned")
>         if (channel != nothing){
>            def result := channel
>            channel := nothing
>            return result            
>         } else {
>            throw("not my box")
>         }
>      }
>   }
>   return [sealer, unsealer]
>}

If I were to fix this problem using KeyKOS facilities, I would make
it so the unsealer doesn't need to invoke box. Probably the
unsealer would hold a key to the instance of domain_creator[1]
which is used to build all the instances of box. Box would keep its
contents in a well-defined capability register, and the unsealer
would use the domain-creator capability to make a domain key[2] to
box and use that domain key to fetch the contents of the
well-defined capability register.

Cheers - Bill

[1] <http://www.agorics.com/Library/KeyKos/Gnosis/67.html>
[2] <http://www.agorics.com/Library/KeyKos/Gnosis/41.html>
-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032