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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
