Slides for today, almost done, FW: Delivery Status Notification (Failure)

[Stiegler, Marc D]

But at 2MB, kicked the google groups complaint that the attachment was larger than 4MB. So here it is zipped

--marcs

> -----Original Message-----
> From: Mail Delivery Subsystem [mailto:mailer...@google.com]
> Sent: Friday, March 05, 2010 9:22 AM
> To: Stiegler, Marc D
> Subject: Delivery Status Notification (Failure)
>
> Hello "Stiegler, Marc D" <marc.d....@hp.com>,
>
> The message you are sending is too large. All messages must
> be less than 4.00 MBytes.
>
> If you have questions related to this or any other Google
> Group, visit the Help Center at
> http://groups.google.com/support/?hl=en_US.
>
> Thanks,
>
> Google Groups
>
>
>
> ----- Original message -----
>
> Received: by 10.101.192.33 with SMTP id
> u33mr1236842anp.28.1267809731601;
> Fri, 05 Mar 2010 09:22:11 -0800 (PST)
> Received: by 10.101.192.33 with SMTP id
> u33mr1236793anp.28.1267809729228;
> Fri, 05 Mar 2010 09:22:09 -0800 (PST)
> Return-Path: <marc.d....@hp.com>
> Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com
> [15.192.0.46])
> by gmr-mx.google.com with ESMTP id
> 24si293462ywh.6.2010.03.05.09.22.08;
> Fri, 05 Mar 2010 09:22:09 -0800 (PST)
> Received-SPF: pass (google.com: best guess record for domain
> of marc.d....@hp.com designates 15.192.0.46 as permitted
> sender) client-ip=15.192.0.46;
> Authentication-Results: gmr-mx.google.com; spf=pass
> (google.com: best guess record for domain of
> marc.d....@hp.com designates 15.192.0.46 as permitted
> sender) smtp.mail=marc.d....@hp.com
> Received: from G3W0630.americas.hpqcorp.net
> (g3w0630.americas.hpqcorp.net [16.233.58.74])
> (using TLSv1 with cipher RC4-MD5 (128/128 bits))
> (No client certificate requested)
> by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id 50C6A30391
> for <fr...@googlegroups.com>; Fri, 5 Mar 2010 17:22:02
> +0000 (UTC)
> Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by
> G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft
> SMTP Server (TLS) id 8.2.176.0; Fri, 5 Mar 2010 17:21:09 +0000
> Received: from GVW1155EXB.americas.hpqcorp.net
> ([16.232.35.139]) by G3W0628.americas.hpqcorp.net
> ([16.233.58.53]) with mapi; Fri, 5 Mar 2010
> 17:21:08 +0000
> From: "Stiegler, Marc D" <marc.d....@hp.com>
> To: "fr...@googlegroups.com" <fr...@googlegroups.com>
> Date: Fri, 5 Mar 2010 17:20:48 +0000
> Subject: Slides, almost ready, for today's dry run "Lazy
> Programmer's Guide to Security"
> Thread-Topic: Slides, almost ready, for today's dry run "Lazy
> Programmer's Guide to Security"
> Thread-Index: Acq8iDKp4r0ObBb0Q6arL+8U7oLYkA==
> Message-ID:
> <DED48AFB6A17C5469D692...@GVW1155EXB.america
> s.hpqcorp.net>
> Accept-Language: en-US
> Content-Language: en-US
> X-MS-Has-Attach: yes
> X-MS-TNEF-Correlator:
> acceptlanguage: en-US
> Content-Type: multipart/mixed;
>
> boundary="_003_DED48AFB6A17C5469D692D2CB60A4AB51DD02F3D95GVW11
> 55EXBame_"
> MIME-Version: 1.0
>
> --marcs
>

[Raoul Duke]

hi,

as an aside, i think using the word Lazy that way everywhere is risky
-- it confused me in the code for Rule #2 since i think of Lazy in
terms of deferring evaluation, a la Haskell etc. :-)

sincerely $0.02.

[Norman Hardy]

On 2010 Mar 5, at 9:25 , Stiegler, Marc D wrote:

> But at 2MB, kicked the google groups complaint that the attachment was larger than 4MB. So here it is zipped
>
> --marcs

I got the zipped file, unzipped it and Keynote (Apple's Power Point) showed it pretty well.
It omitted the code for the money scheme however.
Slides 18 and 19 are devoid of code.
I recall seeing Marcs' preview and I think that there was no protection against counterfeit purses.
This may be my confusion about JavaScript semantics but I suppose that any object with the requisite methods is indistinguishable from an official yield of the code on the screen this morning.

The foundation function to solve this problem in Keykos is the domain-tool which is a primitive object.
It relies on there being distinct keys to the same object.
There are both domain keys and node keys to nodes.
Node keys are more powerful and allow putting arbitrary keys in the node's slots.
One order on the domain-tool is 'create domain' passing a node key and that order returns the weaker domain key to the same node.
The other order on the domain tool takes a domain key and the suspected content of slot one of the node.
If the suspect key matches the key in slot 1, the domain tool returns the strong node key.

The strategy of an object whose job is to create all the members of some clan of objects, is to initially generate some new key whose sole purpose is to 'brand' the clan members it creates.
It places the brand into slot 1 of new nodes, accepts the resulting domain key which is disseminated to others.
The brand is held closely for it allows breaking the abstractions implemented by the code that the new domain obeys.

This solves two problems in the money example:
It allows testing for counterfeit purses.
It allows currencies to be discriminated thus solving the conflation of currencies could be abused to cause fixed integer overflow.

Somewhere a few years ago we spent some time to list a few ways to bottom out this fundamental problem.
I will see if I can find our list.

[Mark Miller]

The exploit you were looking for, in updoc-like notation:

? function area(x, y) {return x*y;}

? function lazyUser(password, z, x, y) {
> print("lazy user area is: " + area(x,y));
> }

? lazyUser("abc",3, 4, 5);
# stdout: lazy user area is: 20

? function area(x,y) { print(area.caller.arguments[0]); return x*y; }

? lazyUser("abc",3, 4, 5);
# stdout: abc
# lazy user area is: 20

[Norman Hardy]

I found the topic area on my web site.
See http://localhost/CapTheory/Language/SchmAmpl.html for a solution to the counterfeit purses.
I think it works in JavaScript as well as Scheme.
The page at http://localhost/CapTheory/Synergy.html is a more general discussion of Language and System synergy.

[Norman Hardy]

Once again: I screwed up the URLs!

I found the topic area on my web site.

See http://cap-lore.com/CapTheory/Language/SchmAmpl.html for a solution to the counterfeit purses.

I think it works in JavaScript as well as Scheme.

The page at http://cap-lore.com/CapTheory/Synergy.html is a more general discussion of Language and System synergy.

Strong typing solves some of these problems nicely it you don't need a dynamic set of seals.

[Marc Stiegler]

Norm,

The example on the slide depends upon the fact that the purse is
running alone in its own separate jvm, and so it can only be accessed
over the wire -- the cast of the Purse to PurseX then suffices to
ensure it is a valid purse.. This is now documented on the slide.

The original Purse protocol, from the Ode, uses a sealer/unsealer pair
to achieve the goals you described. I chose not to use discard that
because I didn't want to discuss sealer/unsealer pairs in this
introductory presentation.

--marcs

> --
> You received this message because you are subscribed to the Google Groups "friam" group.
> To post to this group, send email to fr...@googlegroups.com.
> To unsubscribe from this group, send email to friam+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/friam?hl=en.
>
>

[Marc Stiegler]

So I tried running this in the jsenv shell you can launch as a
bookmarklet from firefox, and it did not work. It appears that
"caller" is implemented but caller.arguments is not public. Did I make
a mistake or does firefox not implement .caller.arguments publicly?
The real question: will I provoke a long complex argument if I use
this code as a demo of javascript's brokenness?

--marcs

function area(x,y) {
print("args: " + area.arguments)
print("caller: " + area.caller.arguments[0]);
return (x*y);
}

function lazyUser(password, z, x, y) {
print("lazy user area is: " + area(x,y));
}

lazyUser("abc", 3,4,5);

--- output ---
args: [object Object]
Error on line 0: Script error.

---------------------------------------------------------

[David-Sarah Hopwood]

Marc Stiegler wrote:
> So I tried running this in the jsenv shell you can launch as a
> bookmarklet from firefox, and it did not work. It appears that
> "caller" is implemented but caller.arguments is not public. Did I make
> a mistake or does firefox not implement .caller.arguments publicly?

It is possible that this attack vector has been fixed in recent versions
of Firefox. I'll check tomorrow which attack vectors have not been
fixed.

--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com

[Marc Stiegler]

> Strong typing solves some of these problems nicely it you don't need a dynamic set of seals.

It even solves more of these problems than I can understand. Oleg
Kiselyov wrote an ocap purse in Haskell several years ago, which I
have kept in my inbox all these years so I can look at it and be
humbly mystified periodically. Oleg's mintmaker can make several
different currencies with their own purses, and at compile time, the
type checking will throw an error you ever try dynamically during
execution to deposit from a purse of one currency into a purse of the
other currency.

--marcs

[Kevin Reid]

It's only weird in its generality. The key is that the type checker is
willing to complain if-and-only-if you try to treat as the same two
values that *are not known to be of the same type* even if nothing
ever determines them to be of any particular fully-concrete type.
Think of it as being a little bit like like sameYet and unresolved
promises in E; you can see promises as being different from each other
even before they've been resolved, even if they never do.

--
Kevin Reid <http://switchb.org/kpreid/>

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> Marc Stiegler wrote:
>> So I tried running this in the jsenv shell you can launch as a
>> bookmarklet from firefox, and it did not work. It appears that
>> "caller" is implemented but caller.arguments is not public. Did I make
>> a mistake or does firefox not implement .caller.arguments publicly?
>
> It is possible that this attack vector has been fixed in recent versions
> of Firefox. I'll check tomorrow which attack vectors have not been
> fixed.

This still works on Firefox 3.5.8, and is probably the simplest attack to
put on the slide, even though it's browser-specific:

function lazyUser(password, z, x, y) {
print("lazy user area is: " + area(x, y));
}

function area(x, y) {
try {throw Error();} catch (e) {print(e.stack.match(/lazyUser.*@/));}
return x*y;
}

lazyUser("abc", 3, 4, 5)

prints:
lazyUser("abc",3,4,5)@

lazy user area is: 20

--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com

[Stiegler, Marc D]

Very cool. Thank you.

--marcs

[Mark S. Miller]

Oh no! ES5-strict doesn't protect against this encapsulation leak!

 

> lazyUser("abc", 3, 4, 5)
>
> prints:
> lazyUser("abc",3,4,5)@
> lazy user area is: 20
>
> --
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
>

--
You received this message because you are subscribed to the Google Groups "friam" group.
To post to this group, send email to fr...@googlegroups.com.
To unsubscribe from this group, send email to friam+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/friam?hl=en.

--
    Cheers,
    --MarkM

[Stiegler, Marc D]

> > function area(x, y) {
> > try {throw Error();} catch (e)
> > {print(e.stack.match(/lazyUser.*@/));}
> > return x*y;
> > }
>
>
>
> Oh no! ES5-strict doesn't protect against this encapsulation leak!

Does Caja? Is this such a deadly example I can't use it to highlight the power of Caja?

--marcs

[Mark S. Miller]

Caja does cleanly protect against this. It is still a good example for the talk.

--

You received this message because you are subscribed to the Google Groups "friam" group.
To post to this group, send email to fr...@googlegroups.com.
To unsubscribe from this group, send email to friam+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/friam?hl=en.

--
    Cheers,
    --MarkM