Hardening the Firefox Sandbox

[Paul Theriault]

Hi all,

Security Engineering has started a project to harden Firefox against attack in 
a post-sandboxed world. It’s early days yet for sandboxing, but conscious of 
the work required, I wanted to raise sandboxing as a topic for discussion, and 
request input towards developing a sandbox security model.

The goal of the hardening project is to make Firefox resilient, even when a 
content process is compromised. Having a restrictive sandbox is not an 
effective security control, if a weak security model or IPC implementation 
flaws lead to privilege escalation. To this end, several efforts are underway:
- Auditing and Testing IPC mechanisms, including:
- Improving fuzzers to focus on IPC bugs (1320851)
-  Auditing IPC mechanisms (IPDL 1041862, MessageManager 1040184)
- Reviewing Firefox components to with respect to sandbox controls

In this latter task, I’ve started documenting the sandbox security model at [1] 
& [2].  [2] is very much a work in progress however. I’ve contacted some groups 
directly, but would appreciate any input here. Please seek me out via email, at 
the all hands (Firefox homeroom) and/or attend the combined session we are 
running with the Platform Integration team on Friday 1pm [3].

Thanks,
Paul


[1] https://wiki.mozilla.org/Security/Sandbox/Process_model 
 
[2] https://wiki.mozilla.org/Security/Sandbox/Hardening 
   WIP, please help!
[3] https://hawaiiallhands2016.sched.org/event/930G/securing-the-sandbox 
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Johnny Stenback]

Double indeed! Very cool to see this happening!

On a logistical note, do we have a meta bug that could track all the bugs
about labeling etc, so that we can hang individual bugs off of that one to
help avoid multiple bugs being filed and worked on for the same thing?

Thanks!


- jst

On Thu, Dec 1, 2016 at 8:31 PM, Kyle Huey  wrote:

> On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:
> > P.S.  This is awesome.  ;)
>
> Indeed.  So glad this is finally happening.
>
> - Kyle
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Kyle Huey]

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:
> P.S.  This is awesome.  ;)

Indeed.  So glad this is finally happening.

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

Re: Runnable labeling for Quantum DOM

[Boris Zbarsky]

On 12/1/16 10:40 PM, Bill McCloskey wrote:

As part of the Quantum DOM project, we're going to be "labeling" all
runnables in the browser to say which document they're operating on.


Is the intent basically to get rid of NS_DispatchToMain/CurrentThread, 
or at least get their usage down to a minimum?



If you want to get started before that, please make sure to
file a bug on what you're doing before you start. That should avoid
duplicating work.


Is there an overall tracking bug people could check to see which things 
are already filed or in-progress?


-Boris

P.S.  This is awesome.  ;)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Runnable labeling for Quantum DOM

[Bill McCloskey]

Hi everyone,

As part of the Quantum DOM project, we're going to be "labeling" all
runnables in the browser to say which document they're operating on.
Labeling will allow us to prioritize some documents over other documents as
well as running different documents concurrently. An API for labeling has
landed in bugs 1305926 and 1320753. Some initial work to label common
runnables is ongoing in bug 1318506.

The only way we can feasibly finish this project is to get help from
everyone working on Gecko. Most runnables are pretty easy to label if you
understand what the code is doing. And if you don't already understand the
code, it's a great way to learn :-).

We have a wiki page that describes the details of labeling:
https://wiki.mozilla.org/Quantum/DOM
You can find examples of labeling in bug 1318506.

If you need more help understanding what's going on, you can contact me
(:billm), Ehsan (:ehsan), Olli (:smaug), or Ben Kelly (:bkelly). We're
going to have a session on Quantum DOM at the Hawaii work week.

I'll send out another email about this after Hawaii with more information
on logistics. If you want to get started before that, please make sure to
file a bug on what you're doing before you start. That should avoid
duplicating work.

Thanks,
Bill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming rename of the marionette-client package to marionette-harness

[Xidorn Quan]

Note that this kind of changes may lead to weird Python error. We have
seen one in bug 1321468.

If you recently see any unexpected Python error when running mach
commands, try execute "./mach clobber python" first. ("./mach clobber"
would *not* work because it only purges things inside the objdir, no
*.pyc files elsewhere.)

- Xidorn

On Fri, Dec 2, 2016, at 04:26 AM, Henrik Skupin wrote:
> Hi,
> 
> Please note that we will soon rename the marionette-client Python
> package to marionette-harness. This work is currently happening on bug
> 1320073. The reason for it is that there is lots of confusion between
> the package names and the folder names in-tree:
> 
> > testing/marionette/client -> marionette-driver
> > testing/marionette/harness -> marionette-client
> 
> As you can see we will fix one part only because we cannot rename
> marionette-driver to marionette-client now. We may consider to do so for
> Firefox 59 which is the overnext ESR release. But the changes for the
> harness package will definitely also land for the 52 ESR release and as
> such will be uplifted to mozilla-aurora soon.
> 
> What does it mean for you?
> -
> 
> If your code is located in in the tree you don't have to do anything. My
> patch will update every single instance where the old package name was
> used.
> 
> For external code you will have to update your package dependencies once
> the code has been landed and the new package released to PyPI. If you
> don't do so, no further updates will be available via PyPI.
> 
> In case you have questions please let us know.
> 
> Thanks,
> 
> -- 
> Henrik Skupin
> Senior Software Engineer
> Mozilla Corporation
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Web2Native Bridge

[Anders Rundgren]

On Thursday, December 1, 2016 at 9:51:36 PM UTC+1, Nicholas Alexander wrote:


Hi Nicholas,

I want to avoid a long (and for other people boring) debate, but I feel that I 
must at least *try* to describe what this is all about...

I would recommend a peek in this document which describes the rationale
https://cyberphone.github.io/doc/web/web2native-bridge.pdf

> The security model of Apps is very poorly understood
> by users and I claim there is no "informed consent".

Right or wrong, this is (IMO) a problem for the OS vendors deal with
and as far as I can see in Android it is evolving.


> I would like the many, many people who have thought about this problem
> involved before we punch a bi-directional hole between these two models.

I have two comments to this:

1. I have tried (really, really hard) to make this happen but it didn't.

2.The Android and iOS URL schemes including Apps that "talk back" through HTTP 
are already firmly established in the market.  My proposal is only about making 
the concept more usable.  BTW, talking back via HTTP is worse security-wise 
than via the "bridge" since App-based HTTP doesn't obey the browser HTTP 
security model.

Application using URL scheme and talking back via HTTP:
https://play.google.com/store/apps/details?id=org.webpki.mobile.android
https://test.webpki.org/webpay-merchant/home

> After all, isn't the Canonical Use Case to provide login credentials
> between Web and App so you get a seamless experience with a single
> sign-on?  That requires some level of trust between the two models.

I'm not sure I understand what you suggesting here.

The App is vetted by an "AppStore" for "Doing the right thing(tm)" when called 
from the Web by a browser recognized by the OS as "genuine".  There are 
use-cases where a service may need to authenticate to the App but that is just 
an option.  What's missing is a better filter mechanism than BROWSABLE but that 
won't happen until the rest is running :-)

I don't know why you say that the JS API is very Android specific.  That's 
certainly not the intent at least.  The Application ID is "java-inspired" but 
if an URL would be better I could change it.

Best regards,
Anders
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: Web2Native Bridge

[Nicholas Alexander]

On Wed, Nov 30, 2016 at 2:40 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On Tuesday, November 29, 2016 at 10:01:38 PM UTC+1, Nicholas Alexander
> wrote:
> Hi Nick,
> Many thanks for your elaborate comments!
>

Heh, that message kept growing and probably could be a blog post when it's
all done :)


> If we begin with security, Android already allows Web-sites to invoke apps
> which they have no specific relation to using the custom URI scheme.  I
> don't see that the ability of "talking back" to the calling Web page would
> introduce new vulnerabilities. I haven't noted any web-site registry
> involved in this operation either, you do a one-time grant for selecting
> browser (if needed) and that's it.  The only quirk seems to be that the
> invocation must be related to a user action.
>

For Web -> App, there is one piece (at least) that prevents the user being
fooled: the invocation must be in response to a user action.  I think the
invoked App could silently process that Intent without indicating anything
to the user, so it would be up to the OS to ensure the user knows *which*
App is handling the action.  I've never used this flow so I don't know if
that happens, or how easy it would be to spoof.


> Anyway, the *long-term* goal for this API is that Web-enabled Apps should
> be *vetted* for this kind of usage which also involves changes in
> "AppStores" and OSes to work.  The need for vetting may also depend on what
> local resources an App access.  This part will likely be vendor-and
> OS-specific.
>

I agree that this would be best at the OS level -- Apple's App Store
certainly vets the URL space associated to an App -- but you might be able
to do it at the browser level too.  It seems like what we're trying to do
is extend the concept of "secure origin" to "secure App".  That is, we need
a dictionary between {SSL certifacte, origin, ...} and {App ID, App
signature, ...}.  If you think of Chrome's Origin Trials, this might be
similar: an origin could register an App ID *and* App signature that the
browser could verify before opening a channel to the App, for instance.  In
fact, this could just be part of the JS API you propose, which is already
extremely Android specific...

In general, my point remains: the security model of the Web is relatively
well understood, and users trust it.  The security model of Apps is very
poorly understood by users and I claim there is no "informed consent".  I
would like the many, many people who have thought about this problem
involved before we punch a bi-directional hole between these two models.
After all, isn't the Canonical Use Case to provide login credentials
between Web and App so you get a seamless experience with a single
sign-on?  That requires some level of trust between the two models.


> A security review of mine regarding the Google/Mozilla/Microsoft take on
> the matter:
> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html
>
>
> If you look into the W2NB docs it says it is an "emulator", not the real
> deal.  The application ID is just a proposal which though should fit
> Android pretty well.
>
> Now over to the actual implementation...
>
> I see two possibilities, one which is more of a PoC allowing people
> testing the core concept on a standard Android phone.  It is still not
> clear to me if this is technically feasible :-(


Having thought about this during my email, I guarantee you it is
technically feasible :)  That doesn't mean it's easy, and definitely
doesn't mean that it's a good idea.


>   Hopefully the links you provided give some answers.


More like starting points, but it will point you in the right direction.


>   I'm also looking into Web Payment API which I (believe) does quite
> similar things albeit in a very specific manner.


I doubt you would find Firefox's (or Chrome's) Web Payments API
implementation instructive at this time, but more power to you if I am
incorrect.


>   If this doesn't work I'm will try another route which I cannot write
> about on a public list.
>
> If Mozilla could consider giving me some support, I would be more than
> happy to build on Firefox!
>

I can commit to answering some questions, but little more.  (In fact, I'm
on parental leave right now, so this is truly a sideline.)  I'm not sure
what else you'd need, other than patience and ingenuity.


> The Web2Native Bridge is the core of a more ambitious effort which among
> many things is about transcending on-line payments from the pitiful state
> it has been in the last 20 years or so.  Well, Google and Apple have
> already done that, but I'm targeting the other 99.9% who don't have a
> platform they can update whenever there's a need.
>

My best wishes,
Nick


>
> Best
> Anders
>
> > Hi Anders,
> >
> > On Tue, Nov 29, 2016 at 9:10 AM, Anders Rundgren <
> > anders.rundgren@gmail.com> wrote:
> >
> > > There are virtually tons of developers out there using Android Intents
> to
> > > start "Apps" from the W

Re: Proposed W3C Charter: Web of Things Working Group

[Benjamin Francis]

Hi Tantek,

On the very serious issues of security and privacy on the Internet of
Things, I agree with you.

On your proposed solution to those problems of somehow trying to slow down
the worldwide deployment of IoT devices (currently forecast to reach tens
of billions by 2020) and prevent any efforts towards standardisation and
the defining of best practices, I couldn't disagree with you more.

We have a whole department at Mozilla dedicated to exploring this space and
it is an organisational goal to attempt to influence standards in this area
in order to embody Mozilla's values into the design and architecture of IoT.

Let's try to make our feedback to the W3C a little more constructive, if we
can.

Ben

On 29 November 2016 at 19:38, Tantek Çelik  wrote:

> To add to this thread, I think there are still fundamental security
> issues, which have only gotten worse, that the charter does not
> address, nor has the incubation to date come even close to
> understanding, much less prototyping / stress-testing.
>
>
> 1. The rapid deployment of WoT/IoT devices poses an existential threat
> to the open internet (something we, Mozilla, are particularly focused
> on protecting more than other orgs are) due to their fundamentally
> worse security.
>
> Since the DDoS attack on krebsonsecurity which motivated our initial
> formal objection based on lack of security considerations in the
> charter and incubation, there was the subsequent DYN DDoS attack which
> took down major sites (Twitter, Github, Reddit, etc.), and that's only
> with the current deployment of insecure IoT devices, by rogue groups
> using open source malware. Basically it proved the security point of
> our formal objection.
>
> WoT/IoT devices are both known to already have worse security, and
> expected to in the future, both in initial design / development, and
> with the lack of incentive to do security software updates due to such
> devices being so low margin, often built by small companies that have
> low life expectancy themselves, then whitelabel bundled into larger
> devices, with no way of updating the embedded software, e.g. the IoT
> cameras used in the DDoS attacks.
>
> The proposed charter (nor anyone's incubation efforts) does/do not
> address these low cost, low margin, low life expectancy company,
> whitelabel embedding issues. All of which have been shown to be real
> problems.
>
> This threat is so bad, that it's not clear that any increased
> deployment of WoT/IoT is "good" for the open internet.
>
> That regardless of tech stack, it is in the interest of maintaining an
> open internet to do what we can to actually *slow down* the deployment
> of of anything WoT/IoT, up to and including opposing standardization
> efforts which seek to *accelerate* the deployment of such devices.
> This is not an "absolute" situation, where we might as well give up
> because it's going to happen anyway like somewhere other than W3C, but
> rather a set of race conditions, where slowing things down anywhere at
> all may still be incrementally helpful (make the internet as a whole
> less vulnerable - it's a spectrum).
>
>
> 2. Increased invasive surveillance.
>
> The above IoT security threat scenarios that we've experienced were
> from small groups or individuals using malware they didn't even write.
> There is an even worse potential threat from insecure WoT/IoT devices,
> and that is state-level actors using those very same existing and
> expected security flaws to turn WoT/IoT devices into the largest mass
> surveillance and data gathering effort in history.
>
> Every sensor on every such device a user puts in their home becomes a
> potential surveillance data gathering node. Note that most the
> above-noted insecure devices used in the attacks were IoT *cameras*.
>
> Nothing from the proposed WoT charter, nor experiments/incubations
> shows any semblance of any of the participants taking this threat
> scenario seriously, nor did any of them raise or document any concerns
> like what happened to Krebs.
>
> (The only person in the W3C context who did provide warnings of the
> kinds of attacks occuring that eventually did happen was Bruce
> Schneier during his talk at the May W3C AC meeting at MIT. But he's
> not involved in W3C WoT/IoT efforts himself.).
>
>
> I don't see any evidence to show that W3C should pursue
> standardization of anything WoT/IoT, and quite the opposite, that
> we're at a point of WoT/IoT industry immaturity where product
> development and deployment is both hurting the internet, and
> presenting a potentially even larger threat to users of such products
> being transparently, illegally*, invasively surveilled by their
> governments hacking the devices in their own homes (*but recently
> approved in the UK[1]), and thus should be opposed.
>
>
> If anything, we (Mozilla) should be reaching out to EFF and any other
> W3C Members who value an open internet and respecting users privacy
> more than profit (perhaps university memb

Upcoming rename of the marionette-client package to marionette-harness

[Henrik Skupin]

Hi,

Please note that we will soon rename the marionette-client Python
package to marionette-harness. This work is currently happening on bug
1320073. The reason for it is that there is lots of confusion between
the package names and the folder names in-tree:

> testing/marionette/client -> marionette-driver
> testing/marionette/harness -> marionette-client

As you can see we will fix one part only because we cannot rename
marionette-driver to marionette-client now. We may consider to do so for
Firefox 59 which is the overnext ESR release. But the changes for the
harness package will definitely also land for the 52 ESR release and as
such will be uplifted to mozilla-aurora soon.

What does it mean for you?
-

If your code is located in in the tree you don't have to do anything. My
patch will update every single instance where the old package name was used.

For external code you will have to update your package dependencies once
the code has been landed and the new package released to PyPI. If you
don't do so, no further updates will be available via PyPI.

In case you have questions please let us know.

Thanks,

-- 
Henrik Skupin
Senior Software Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

ATMOv2 Domain Change Complete

[Blake Imsland]

Hello All,

This is a followup email to let everyone know that we've completed
switching the main ATMO domain (analysis.telemetry.mozilla.org) to point to
ATMOv2. If you had previously been using atmo.prod.mozaws.net, this is the
same service (there's a redirect in place) and you should use the main
domain going forward.

If you find any bugs please report them here:

https://mzl.la/2fvBAj7

Any questions, feel free to reach out to me in IRC in #telemetry and I'll
do my best to answer.

Cheers,
Blake
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform