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
***************************************
