Meant to ask earlier -- for SFI/CFI: -- How is JIT'd code handled? E.g., the JIT also outputs instrumented code and we trust whoever ran the JIT?
-- Are return-to-libc attacks in the threat model or is that too academic? A seemingly realistic example of return-to-libc would tricking the browser into JITing something along a normal control flow, akin to SQL injection. - Leo > > > Message: 1 > Date: Tue, 24 Jul 2012 12:01:31 -0700 (PDT) > From: Ian Melven <imel...@mozilla.com> > To: Brendan Eich <bren...@mozilla.com> > Cc: dev-servo@lists.mozilla.org, Patrick Walton <pwal...@mozilla.com>, > rob...@ocallahan.org > Subject: Re: [dev-servo] State of Servo > Message-ID: <882102013.791286.1343156491144.javamail.r...@mozilla.com> > Content-Type: text/plain; charset=utf-8 > > > Hi, > > thanks for all the links to those papers on CFI etc, Brendan, > i will give them a read. i'm familiar with commercial control flow > restricting products (and bypassing them) from a previous job :) > > Native Client is very interesting - i've never really looked at it, > and this seems like a good time to study up on how it's implemented. > > ----- Original Message ----- > From: "Brendan Eich" <bren...@mozilla.com> > To: rob...@ocallahan.org > Cc: dev-servo@lists.mozilla.org, "Patrick Walton" <pwal...@mozilla.com> > Sent: Wednesday, July 11, 2012 9:44:01 PM > Subject: Re: [dev-servo] State of Servo > >> I'm more concerned about runtime bugs -- the usual free memory read >> during a virtual call. Rust will have vtbls, IIRC, and it takes only one >> rooting or refcounting bug to enable an attacker to reclaim the live >> object's vtbl. At least, this has been the bane of browsers' existence >> for over seven years. > > yes, this is my concern also - what i like to call 'post exploitation', > when control has already been taken by the attacker. at this point CFI > and other such techniques have been bypassed via implementation flaws > etc. for example - i'm not convinced a Chromium-like 'capabilities' (basically > a whitelist) model is necessarily the Right Thing To Do, but it's > worth thinking about IMO. > >>> I don't think adding levels of sandboxing or verification to Servo >>> will be important anytime soon, though. Those are orthogonal problems >>> that are only worth solving once we have a browser engine worth >>> defending, and can be readily solved at that point. > >> The topic already came up, and the NaCl issue was filed. I honestly >> don't know when we should get into this level of Servo security, but >> "adding Security later" is an anti-pattern. I don't believe we can use >> NaCl targeting Pepper in Servo, for instance. Seems worth a discussion >> up front, even if we defer. > > right, this is exactly my concern - there are pieces of the design of the > current > desktop Firefox that make content/chrome process separation (and hence > sandboxing > in the Chromium sense with different restrictions for processes with different > responsibilities) quite difficult. Addons are another big pain point when > it comes to capabilities-type sandboxing unless they run in their own process. > > My goal is bringing this up now isn't to necessarily get into this level > of security at this point, more to raise awareness in the hope > of making architectural decisions early on that take security concerns into > account. > > thanks, > ian > > > > > > ------------------------------ > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > > > End of dev-servo Digest, Vol 7, Issue 4 > *************************************** _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
