ES4 Security

[Brendan Eich]

On May 17, 2008, at 11:55 PM, Steven Mascaro wrote:

> The current browser security model is broken.

Ok, sure.

> Any security exploit that has 'cross-site' in it's name need not  
> exist today.

Lots of problems "need not" exist today, but they do. Solving them  
requires making changes. We "need" (I do, at any rate) to be specific  
and detailed about exact problem and proposed solution(s), to talk  
sensibly and evaluate the likely effects of changes from this point  
forward. I'll try to be specific below, without getting stuck in  
details.

"Cross-site" exploits happen on the server side too. They're possible  
in proxies and other kinds of gateways. They arise when data  
originating from different trust domains mix in ways that lose track  
of each datum's trust label (ignore policy questions, including the  
folly of putting the user in the loop). The mixing involves control  
flow, so the problem is not solvable by data-labeling alone.

> The solution for browsers is simple: do not *automatically*  
> transmit private information (usually cookies) to 3rd parties in a  
> transaction.

This is so vague it's hard to respond to usefully, but notice that  
(in Parkerian Hexad terms) you're talking about Confidentiality here.

The parenthetical non-vague bit about cookies does not help, because  
cookies are only one asset threatened by XSS. Browsers have cookie  
controls already, we're working on improvements to them and their  
defaults, but XSS goes way beyond cookies.

> Once this problem is solved, ES4 *does* *not* need RO/DD/IH for  
> security. (IH=information hiding.)

Now you've changed the subject to Integrity.

> Note, this post is *only* about security (and privacy).

We are not out to solve "security" or any such fluffy problem-name in  
ES4. Anyone claiming to deliver "security" solely by means of a  
"secure programming language" is selling you a bridge. See http:// 
lambda-the-ultimate.org/node/2773 for a recent LtU thread (and cue  
David Teller and Mark Miller ;-).

> It is not about whether RO/DD/IH can make development/maintenance  
> easier.

The main issue in ES4 is not "development/maintenance", it's being  
able to make sane type judgments (static or dynamic, doesn't matter),  
at all.

A secondary issue is Integrity as an information security property.  
Integrity alone doesn't really "solve" whole problems on the real- 
world level of "prevent entire class of security exploit (XSS)" or  
"make a usable and 'safe' yet powerful browser-based programming  
language". But Integrity is an end-to-end property that you can build  
proofs and helpful automations on top of, and without it you're too  
often pretty much screwed.

I implemented a dynamic data tainting security model (opt-in) for  
Netscape 3. Helpful testers actually beat on it, hard. Its goal of  
Confidentiality was frustrated by (a) lack of static analysis to help  
"untaint the pc" (tainting the pc is required to deal with Denning's  
"implicit flows" -- see above about data labeling being  
insufficient); (b) lack of Integrity to make such analysis practical,  
if not feasible in the first place.

Ignoring ES4, browsers have struggled with mutable (and shadowable,  
for initialisers per ES3!) Object and Array bindings, and mutability  
in general. Check out the open source bug databases at  
bugzilla.mozilla.org and webkit.org (both, one can cite bugs in  
either; and closed-source browsers' bug databases, if they're worth  
anything, should have similar bugs). Just one example:

https://bugzilla.mozilla.org/show_bug.cgi?id=376957

Jesse Ruderman's comment 0 is worth reading in full. See how browser  
have to engineer defense-in-depth (so should everyone; I'm not  
whining here).

In the real world this means considering the likelihood of web app  
developers failing to authenticate carefully, or configure and check  
MIME types. And of course, even if web app devs were perfect, there'd  
still be browser bugs, mashup novelties, wireless network IP  
addressing and DNS threats, etc.

Here's another "privacy" issue, not solved in any browser I know of,  
dictated by web standards and user expectations:

https://bugzilla.mozilla.org/show_bug.cgi?id=147777

In the bug, David Baron even explores "cross-copying" (padding  
execution times along alternate paths to close timing channels). This  
is still a research problem.

And what's made this bug less severe, besides its ubiquity in all  
popular browsers, is the fact that remote tracking of browser  
"visited" history is unfortunately "easy" using a number of  
techniques, ignoring CSS (Cascading Style Sheets, not XSS).

Still, I would like to fix bug 147777. I have some ideas, which  
involve hybrid information flow propagating through CSS layout, but  
they're vague and challenging -- researchy, in a word.

"Security" is a big topic, not something to simplify with too few  
words. You cannot reduce a difficult argument to a short-hand formula  
that "proves" ES4 should let Object or Array be overridden (or not).

Yet it seems to me you've made such a reduction: "Confidentiality,  
not Integrity, is the property to enforce against XSS threats;  
therefore Integrity does not matter for 'security'" (if I may  
paraphrase your brief message with too few -- even fewer -- words  
myself).

Kris Zyp tried this kind of stunt-argument with the "AOP" would-be  
root password on this list, and I hope I put a stake through the  
heart of that three-letter-acronym vampire. (I recently asked Mitch  
Wand about AOP, which he'd spoken about at ICFP 2003 and researched a  
bit, in part to tease him for touching such an overhyped topic; he  
replied wittily: "sometimes someone coughs and you start sneezing." ;-)

At the level of "es4-discuss", we can keep arguing and try to come to  
a deeper understanding; I'm game. But the idea that Confidentiality  
is enough, Integrity be damned, requires more than what you've  
written to make a convincing argument. In info-sec theory and  
practice, Confidentiality depends and builds on Integrity.

> (I've keep this post short, given the lack of response to my last  
> ridiculously long post. :) Opposing opinions very much welcomed.)

I think you kept it too short. :-/

/be