On Wed, Jul 11, 2018 at 6:25 PM, Karl Tomlinson <mozn...@karlt.net> wrote:
> Is there a guideline that should be used to evaluate what can
> acceptably run in the same process for different sites?
>
This is on me to write. I have been slow at doing so mainly because there's
a lot of "What does X look like and where do its pats run" investigation I
feel I need to do to write it. (For X in at least { WebExtensions, WebRTC,
Compositing, Filters, ... })
> I assume the primary goal is to prevent one site from reading
> information that should only be available to another site?
>
Yep.
On Wed, Jul 11, 2018 at 6:56 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:
> On Thu, Jul 12, 2018 at 11:25 AM, Karl Tomlinson <mozn...@karlt.net>
> wrote:
>
> > Would it be easier to answer the opposite question? What should
> > not run in a shared process? JS is a given. Others?
> >
>
> Currently when an exploitable bug is found in content process code,
> attackers use JS to weaponize it with an arsenal of known techniques (e.g.
> heap spraying and shaping). An important question is whether, assuming a
> similar bug were found in a shared non-content process, how difficult would
> it be for content JS to apply those techniques remotely across the process
> boundary?
You're completely correct.
> That would be a pretty interesting problem for security
> researchers to work on.
>
It's always illustrative to have exploits that demonstrate this goal in the
target of interest - they may have created generic techniques that we can
address fundamentally (like with Memory Partitioning or Allocator
Hardening). But people have been writing exploits for targets that don't
have a scripting environment for two decades or more, so all of those are
prior art for this sort of exploitation. This isn't a reason not to pursue
this work, and it's not saying this work isn't a net security win though!
I have been pondering (and brainstormed with a few people) about creating
something Google native-client-like to enforce process-like state
separation between threads in a single process. That might make it safer to
share utility processes between content processes. But it's considerably
less straightforward than I was hoping. Big open research question.
Use of system font, graphics, or audio servers is in a similar bucket I
> > guess.
> >
>
> Taking control of an audio server would let you listen into phone calls,
> which seems interesting.
>
> Another question is whether you can exfiltrate cross-origin data by
> performing side-channel attacks against those shared processes. You
> probably need to assume that Spectre-ish attacks will be blocked at process
> boundaries by hardware/OS mitigations, but there could be
> browser-implementation-specific timing attacks etc. E.g. do IPDL IDs
> exposed to content processes leak useful information about the activities
> of other processes? Of course there are cross-origin timing-based
> information leaks that are already known and somewhat unfixable :-(.
Yup!
-tom
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
