Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

[Andrew McCreight]

On Wed, Aug 3, 2016 at 2:37 PM, Robert O'Callahan 
wrote:

> On Wed, Aug 3, 2016 at 4:10 PM, Michael Howell  >
> wrote:
>
> > I can think of one advantage right now: by having script and layout in
> > separate processes, a compromised script thread doesn't automatically
> give
> > an attacker the ability to produce malformed display lists that draw
> > outside the tab boundary.
> >
>
> Seems to me this can easily be prevented by clipping the display lists
> produced by content layout.
>

Even outside of compromise script threads, Firefox gets a steady trickle of
bugs where somebody figures out how to get some content-controlled UI thing
(like a context menu) to overlay privileged UI like the URL bar. These are
usually fairly weak as far as spoofing attacks go, but I think it would be
nice if  banning content from overlaying chrome could be done, changing a
front end bug from a possible exploit into a weird graphical glitch. UI
designers might not like such a hard restriction, though.

Andrew


> Rob
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Questions about constellation, sandboxing and multiprocess

[Andrew McCreight]

On Wed, Aug 3, 2016 at 8:35 AM, Jack Moffitt  wrote:

> I asked ekr how much this mattered, and he thought it was important. I
> don't think anyone has pointed me to a documented attack, but it
> definitely seems like the kind of thing that could be done somehow.
>

It seems like it will be important in the long run, but the current state
of the art is that every browser is getting exploited every year at
Pwn2Own, really badly. This is from an article on Pwn2Own this year: "In
fact, every successful attack at Pwn2Own this year achieved system or root
privileges, which has never happened at the event before." [1]

In a world where a sophisticated attacker can get root privileges, I
wouldn't spend too much time worrying about intraprocess attacks.

If you do want to think about it, I'd first read over the work that Chrome
people have already put into thinking about this issue:
http://www.chromium.org/developers/design-documents/site-isolation

I'm not sure how much they have actually shipped from this initiative,
though.

Andrew

[1]
http://venturebeat.com/2016/03/18/pwn2own-2016-chrome-edge-and-safari-hacked-460k-awarded-in-total/


> How we allocate domains to content processes is an open question. It's
> not clear whether we want to segregate high value targets or low value
> targets. But the infrastructure required is the same either way pretty
> much. The only strategy we know won't work is round-robin/random,
> since the attacker could just keep creating domains until they land in
> the right process.
>
> To be clear, I don't think there is very much code complexity here
> over the normal 2 process (chrome + content) solution. We already have
> to have process spawning and IPC. The only thing that changes here is
> code to decide where to spawn new pipelines.
>
> Implementation wise, we currently spawn a new process per script
> thread. I think we should change this to spawn a single, sandboxed
> content process that contains all the pipelines. Later we can expand
> this once it's more clear how we should allocate pipelines to
> processes.
>
> jack.
>
> On Wed, Aug 3, 2016 at 2:53 AM, Till Schneidereit
>  wrote:
> > I wonder to which extent this matters. I'm not aware of any real-world
> > instances of the mythical cross-tab information harvesting attack. Sure,
> in
> > theory the malvertising ad from one tab would be able to read information
> > from your online banking session. In practice, it seems like attacks that
> > gain control of the machine are so much more powerful that that's where
> all
> > the focus is.
> >
> > Additionally, it seems like two content processes, one for normal sites,
> > one for high-security ones (perhaps based on EV certificates), should
> give
> > much of the benefits. Or perhaps an additional one for low-security ones
> > such as ads (perhaps based on tracking blocking lists).
> >
> > On Wed, Aug 3, 2016 at 5:43 AM, Jack Moffitt  wrote:
> >
> >> Each process is a sandboxing boundary. Without security as a concern
> >> you would just have a single process. A huge next step is to have a
> >> second process that all script/layout threads go into. This however
> >> still leaves a bit of attack surface for one script task to attack
> >> another. How many processes you want is a tradeoff of overhead vs.
> >> security.
> >>
> >> So really it should say "more process more security".
> >>
> >> jack.
> >>
> >> On Tue, Aug 2, 2016 at 9:09 PM, Patrick Walton 
> >> wrote:
> >> > It's not a stupid question :) I actually think we should gather all
> >> script
> >> > and layout threads together into one process. Maybe two, one for
> >> > high-security sites and one for all other sites.
> >> >
> >> > Patrick
> >> >
> >> >
> >> > On Aug 2, 2016 6:47 PM, "Paul Rouget"  wrote:
> >> >>
> >> >> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt 
> wrote:
> >> >> >> First, is multiprocess and sandboxing actively supported?
> >> >> >
> >> >> > I tested this right before the nightly release, and it was working
> >> >> > fine and didn't seem to have bad performance. Note that you can
> run -M
> >> >> > or -M and -S, but not -S by itself (which doesn't make sense). Also
> >> >> > note that -M and -S probably don't work on Windows or Android
> >> >> > currently.
> >> >> >
> >> >> >> Is Servo tested with the "-M -S" options?
> >> >> >
> >> >> > We do not have automated testing of these yet.
> >> >> >
> >> >> >> What's the status of the sandbox?
> >> >> >
> >> >> > Should work on Mac and Linux, but hasn't been audited.
> >> >> >
> >> >> >> Is there any reasons for these options to not be turned on by
> >> default?
> >> >> >
> >> >> > They should be, although I think we wanted to fix perf issues
> running
> >> >> > the WPT suite and get all the platforms working first. We should
> >> >> > probably test both configurations.
> >> >> >
> >> >> >> Do we want to enable "-M -S" for 

Re: [dev-servo] Planning to experiment with inline storage for DOMString / webidl binding codegen

[Andrew McCreight]

For what it is worth, Gecko uses a single-entry per-zone cache for
converting the result of JS strings to DOM strings in getAttribute (I
think). bz added this in bug 773520, and it has had a few refinements since
then. Maybe some kind of caching would help Servo, too.

Andrew

On Wed, Dec 2, 2015 at 1:05 PM, Alan Jeffrey  wrote:

> Well, I tried eliminating the buffering, but I still didn't get any perf
> benefit, if anything there was a degrade. Sigh.
>
>
> https://github.com/asajeffrey/servo/commit/1533238eb822688572a04d5bd6eb8ac88297
>
> On Wed, Dec 2, 2015 at 10:49 AM, Nick Fitzgerald 
> wrote:
>
> > And there is also ArrayString[0] from the arrayvec crate[1]. I was
> > considering reusing this and getting rid of the fixed size
> `InlineString` I
> > rolled myself as ArrayString is almost identical.
> >
> > [0] http://bluss.github.io/arrayvec/doc/arrayvec/struct.ArrayString.html
> > [1] https://crates.io/crates/arrayvec
> >
> > On Tue, Dec 1, 2015 at 6:03 PM, Simon Sapin 
> wrote:
> >
> > > On 02/12/15 02:39, Nick Fitzgerald wrote:
> > >
> > >> I've created a crate[0] that provides a mostly drop-in replacement of
> > >> std::string::String but with inline storage for small strings to avoid
> > >> heap
> > >> allocation.
> > >>
> > >> [0]https://github.com/fitzgen/inlinable_string
> > >>
> > >
> > > There’s also [1], already in used in Servo in some places, which
> behaves
> > > like Vec but stores items inline up to a certain length. I’ve also
> > been
> > > playing with [2] to be like String but with a generic backing storage.
> > > (I’ve used it in [3] to return a single code point in UTF-8 as
> > > StringWrapper<[u8; 4]>.)
> > >
> > > Would it make sense to converge with some of these?
> > >
> > > [1] https://github.com/servo/rust-smallvec
> > > [2]
> > >
> >
> https://github.com/SimonSapin/rust-std-candidates/blob/master/string-wrapper/lib.rs
> > > [3] https://github.com/SimonSapin/rust-utf8
> > >
> > >
> > > --
> > > Simon Sapin
> > >
> > > ___
> > > dev-servo mailing list
> > > dev-servo@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-servo
> > >
> > ___
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> >
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Multiprocess safety

[Andrew McCreight]

On Fri, Jun 19, 2015 at 3:21 AM, Robert O'Callahan rob...@ocallahan.org
wrote:

 On Fri, Jun 19, 2015 at 7:10 PM, Patrick Walton pwal...@mozilla.com
 wrote:

  In theory you can use cmsg on POSIX systems to send channels over
  channels, by treating channels as file descriptors. I tried this first,
 and
  I believe it actually worked well on Linux. But on Mac I ran into all
 sorts
  of (as far as I can tell) kernel bugs, including kernel panics and data
  loss. It might still be possible by using Mach ports instead on the Mac
  (and I started to sketch that code), but I eventually figured it was
 going
  to be cleaner to just stop sending channels over channels across process
  boundaries.
 

 Firefox IPDL sends file descriptors over sockets on Mac using cmsg. There
 is a kernel bug where an in-flight file descriptor is not kept open by the
 kernel, so you must keep it open on the sender side until the message is
 acknowledged. I don't know about any kernel panics related to that feature.


Patrick, if you look at the various stuff in the chromium IPC directory
that is guarded by ifdef OS_MACOSX, you can see some of the workarounds.
For instance:
http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/chrome/common/ipc_channel_posix.cc#592




 On Windows you should be able to rig something up using DuplicateHandle. I
 think Firefox uses this on Windows but I'm not sure.

 Rob
 --
 oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
 owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
 osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
 owohooo
 osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
 oioso
 oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
 owohooo
 osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
 ooofo
 otohoeo ofoioroeo ooofo ohoeololo.
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo

___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] JS engine (meeting notes)

[Andrew McCreight]

- Original Message -
 https://github.com/servo/servo/wiki/Workweek-alt-js
 
 I'm pleased with the Table discussion until mid 2015 outcome :-).
 
 It might make sense at some point to have a super secure Servo build
 where you plug in a JS interpreter and simple GC written in Rust, but I
 can't see a viable general-purpose browser without a complex multitier JIT.
 
 In the long term, we should be able to have that plus security by
 translating SM into Rust and introducing some kind of TAL/PCC safety
 checking of generated code, maybe with some offline theorem proving for
 critical bits like GC. The state of the art in this area is advancing
 reasonably quickly. But I can't see any rewrite the JS engine project
 making sense for Servo even in the medium term unless the landscape changes
 dramatically (e.g. massive quantities of new resources fall from the sky).

From the JS engine bugs I've seen flying by, they mostly seem to involve 
violation of the internal invariants of the representation of the JS data 
structures, say, rather than buffer overflows or UAFs, so I don't know how much 
Rust would help improve the security story there.

If anybody wants to get a sense of some of the bugs in the JS engine, search on 
bugzilla for bugs with sec-high or sec-critical keywords that have a resolution 
of FIXED and are assigned to bhackett.  When he attaches patches to bugs, he 
usually includes a nice description that at least gives you a sense of what is 
going wrong.  For instance, from bug 842424: There was a missing use of 
newKind that caused 'new' objects which are supposed to have singleton type to 
not have singleton type.  Their properties were then cleared, causing them to 
go out of sync with their type information --- they were marked as definitely 
having properties when they actually didn't have any, and Ion invoked a pre 
barrier on a slot of the object which did not correspond to any property, which 
in debug builds is a poisoned ObjectValue(42).

So I'd say that given all of the engineering work it would take to get a 
vaguely competitive JIT a better use of time would be an experiment to add some 
more dynamic checking (like PCC/TAL) to SM.  One fun property of PCC/TAL is 
that you don't even have to run the produced code in order to find errors, 
which is particularly nice if you are looking for things like errors in array 
bounds checking elimination where hitting a case that does something bad could 
be tricky.  It might really increase the efficiency of fuzzing per CPU hour, 
though I'm not sure if anybody has ever tried to fuzz a PCC/TAL compiler before.

Andrew

 
 Rob
 --
 oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
 owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
 osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
 owohooo
 osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
 oioso
 oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
 owohooo
 osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
 ooofo
 otohoeo ofoioroeo ooofo ohoeololo.
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo
 
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Servo memory usage

[Andrew McCreight]

- Original Message -
 Rust does have 2MB stacks by default. These giant numbers are surprising.

In Gecko, we've found that almost anytime we start measuring something, we find 
something surprising. ;)

Andrew
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] meeting notes (COW DOM)

[Andrew McCreight]

- Original Message -

Not to derail this further with a defense of the CC, but...

 CC is still a performance and memory and safety problem.

At this point, I think the GC is a bigger performance problem. ;) Ok, so it is 
doing much more stuff than the CC...

 Yeah, I shouldn't have mentioned safety there, since the fundamental
 problem is the same whether or not you use CC or GC. You still have to
 teach the JS engine or the CC about the object graph.

Yeah, automatic memory management of C++ is just a pain.  The CC is a little 
nicer because mistakes are (often) only leaks, not arbitrary code execution, 
like they are with GC.  Oilpan seems to be dealing with this problem by using 
static analysis to check the correctness of their trace methods.  I 
investigated something like that for the CC using Dehydra, but there are a lot 
of weird traverse methods out there.

 We use compiler support for this in Rust, thankfully, eliminating the
 safety and annoyance-of-writing-trace-hooks problems (via abuse of the
 serialization module--this should eventually migrate to something better).
 
 I guess depending on whether you include leaks as part of safety, you
 have to be careful to make sure your ForgetSkippable optimizations to
 throw things out of the purple buffer are correct.

Leaks should not be put in the same category as arbitrary code execution, 
because adversaries are not going to exploit obscure engine bugs to cause 
leaks.  You only need to worry about what people hit in practice.

In about 2.5 years of ForgetSkippable optimizations, we've only had a handful 
of bugs.  I was certainly worried about things being removed from the graph 
that shouldn't have been, but it isn't really a problem in practice.

Anyways, I think the main ugliness of the cycle collector is in the integration 
with the garbage collected heap, and all of the unmark gray stuff.  If you can 
get the perf and implementation costs you need with just one collector, then 
great.  (I think the latter is an overlooked benefit of the CC for Gecko, in 
that we can mostly just ignore it and it does its thing.)

 I understand that they're necessary, but the purist in me really dislikes 
 wiring
 application-specific logic into the garbage collector :)

The collector itself just runs per-class callbacks for forget skippable, so I 
think it isn't too bad all told.

The reality is that if you really care about perf, and you are using your 
collector for a specific program you also control and care about, you are going 
to need to take advantage of whatever information you can.  For instance, the 
JS allocator is effectively aware of which tab each object is in, so that it 
can put them in the same zone, because things in the same tab will likely have 
similar lifetimes.

Andrew


 
 Patrick
 
 ___
 dev-servo mailing list
 dev-servo@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-servo
 
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Quark : A Web Browser with a Formally Verified Kernel

[Andrew McCreight]

- Original Message -
 http://goto.ucsd.edu/quark/

Relatedly, this MWR Labs writeup on their Chrome exploit is kind of fun.

Looking at the crash dumps, we observed that the following undocumented system 
call triggered the crash

In cases where the last argument to NtUserMessageCall is an even number and is 
non-zero, the allocation function and the function performing the copy 
operation will interpret this value differently. As an example, if we passed 
the value 2 as the last argument, the allocation function would treat this as 
Boolean true, and allocate a buffer big enough to hold the ASCII representation 
of the string. When the function performing the copy operation is called, it 
would copy the string as a WCHAR value, because the least significant bit of 
the value 2 is not set.

https://labs.mwrinfosecurity.com/blog/2013/09/06/mwr-labs-pwn2own-2013-write-up-kernel-exploit/


They also have a set of slides on the first part of the attack, to take over 
the child process:

https://labs.mwrinfosecurity.com/system/assets/538/original/mwri_polishing-chrome-slides-nsc_2013-09-06.pdf
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo