Devdatta let me know about Microsoft's new pre-release (Tech Preview) of EMET, their exploit mitigation toolkit, see http://blogs.technet.com/b/srd/archive/2012/07/24/emet-3-5-tech-preview-leverages-security-mitigations-from-the-bluehat-prize.aspx
This uses some of the techniques Microsoft has chosen as winners of their defensive security contest (a pretty cool application of the same bug bounty program that engages the security community at large with finding our vulnerabilities). The blog post also references this classic article on evasion techniques : http://www.phrack.org/issues.html?issue=62&id=5 Dev asked me for the link to this article when I mentioned it in a previous post, i thought some other folks may be interested. thanks, ian ----- Original Message ----- 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 Sent: Tuesday, July 24, 2012 12:01:31 PM Subject: Re: [dev-servo] State of Servo 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
