Security/Reviews/JetPack2011-20/12

Items to be reviewed: SDK 1.0 and current featureset reviews Agenda:

Introduce Feature

• not a lot new since 1.0, just want to get a regular schedule of discussing new stuff
• other teams want to use JetPack (i.e. BrowserID) as a regular way into new releases
  • that would mean shipping JetPack code in Firefox (or as a "default add-on") for the first time
• this meeting will focus on the security model for JetPack

JetPack vision

• An add-on can do anything the browser can do, but we don't want add-ons to surprise users (or have security holes exploited?).
  • add-on shows up at AMO, gets reviewed and if all is well, published
  • JetPack add-ons will make life easier for AMO reviewers, by providing new tools

JetPack security model

Pagemod

• Separate context in which addons manipulate content. The "pagemod" part can only communicate with the main part using JSON (serialized to a string). (This is both a security feature and an e10s-compatibility feature.)

Modules

• In the early days of JetPack, I heard some interesting ideas. Which of those were implemented, which are yet to be implemented, and which were discared?
  • Hmm, not sure, would need to know the specifics of those interesting ideas! :-)
  • Privileges are not shown to users. They are primarily for AMO reviewers and secondarily for preventing bugs in extensions from being severe vulnerabilities.
  • Extensions can be split into pieces with different privileges. For example, one piece can have filesystem read access, and expose to another piece the contents of a specific file.
    • Does that mean the ability to call that module is itself a privilege?
      • Yes, the packager generates a module dependency graph based on an analysis of the addon's code; at runtime, the module loader then consults that graph to determine which modules can require which other modules. So a module that doesn't explicitly require another module at package time cannot access it at runtime.
• Each module works in a different sandbox/compartment. https://bugzilla.mozilla.org/show_bug.cgi?id=672443 expensive.
  • They could be changed to use different sandboxes in a single compartment. They could still be prevented from sharing (unfrozen?) global objects.
    • But then you have ye olde getters-and-setters, __parent__, dynamic language mess.
• Each module separation reduces (or combines) privileges.
• long term goal is to have manifest signed by the reviewer
  • and possibly the browser would contain public keys and the user could decide which reviewers to trust

Packaging

• Will packaging happen on AMO?
  • It does, for addons built with Add-on Builder, our web app for building addons that is integrated into AMO at builder.addons.mozilla.org.
  • It could for locally developed addons; we've considered making the SDK produce a source package that gets uploaded to AMO, which then produces the distributable XPI.
  • But the primary reason to do so would be to control key components of the XPI, like the module loader and the bootstrapper; and we can also do that by landing those components in core Firefox so we don't ship them with each XPI.

Questions

• Does any of this have to change due to the speed/memory issues that have been discovered? e.g.
  • No, so far no such issues have suggested fundamental changes in the model.

What solutions/approaches were considered other than the proposed solution?

Why was this solution chosen?

Any security threats already considered in the design and why?

Threat Brainstorming

Pagemod

• Forcing all this serialization means extensions (that need structures that can't be expressed easily using JSON) are going to be full of parsers :(
  • HTML?
• Are pagemod pieces intended to be compromised? Is this clear to add-on authors?
  • No, we intend to keep them as safe as possible and warn authors when they do something that might be unsafe.
  • In particular, access to DOM objects is mediated by wrappers (these days I think this is XrayWrapper) that prevent content from spoofing DOM object properties.
    • In some cases addons get access to unwrapped objects, because XrayWrappers cannot yet wrap certain objects. This is considered a bug to be fixed.
  • An experimental API called `unsafeWindow` gives addon developers access to unwrapped DOM objects (similar to the same-named API in Greasemonkey).
    • Will proxy bypass through unsafeWindow remain enabled by default, or is it being replaced by something else?
      • We tag unsafeWindow "experimental" because we're actively looking for a safer way to give addons access to the unwrapped objects; but we don't currently have any idea what this is.
        • Maybe there should be a piece of the pagemod, or a pagemod mode, where the code runs with the principal of the page (like a bookmarklet)
          • That wouldnt solve the problem of communication with the addon (addon <-> content script), would it?
  • Similar to GreaseMonkey? Similar to how extensions work now?
    • Similar to Greasemonkey.
  • the page mod script are conceptually similar to a GM user.js, the jetpack is more like Greasemonkey itself.
    • I would say that the SDK is like Greasemonkey, the page mod is like a GM user.js, and the addon (jetpack) is somewhere in-between: more authority than the page mod, less authority than Greasemonkey or the SDK itself (depending on which modules it requires and in particular whether or not it does require('chrome')).

Modules

• Namespace conflicts? How does an addon know that it's getting the right "TwitterAPI" module, especially if it's a third-party add-on?
  • within a XPI there is only the one TwitterAPI. In the add-on builder site you would specify which other user's TwitterAPI you wanted to include by GUID or URL (right now you'd just copy it).
  • Hash (SHA-256) of the contents of included module is compared to a stored hash in the manifest
    • What's included in the hash?
      • Just the contents of the JS file, not the module-graph metadata.
• When two extensions both use TwitterAPI, is there a single TwitterAPI instance or two? Either way, how do we ensure the two users don't stomp on each other?
• Are all modules importable? A "main" module might be surprised if another add-on imports it.
  • Yes, all modules are importable, including "main", although one addon can't import another addon's modules. The ability to import "main" has a use case: libraries that want a single entrypoint into their functionality. Nevertheless, the ability to import "main" seems like overgeneralization, and we've grown skeptical of libraries (collections of one or more modules that are sharable between SDK installations) and are thinking about making modules individually sharable.
• When author submits a prebuilt JetPack extension to AMO, and AMO "detects it as having been built by JetPack", how do we make sure it wasn't tampered with?
  • I'm a bit fuzzy on exactly how the reviewers currently do this (and tooling is being planned for Q4), but the general story is that the reviewers check the components of the XPI that supposedly came from the SDK to make sure they match the version of the SDK they supposedly came from. If not, the reviewers review those components in addition to those that come from the addon developer.
  • It isn't unheard of for addon developers to modify SDK-provided modules to make them do something the module doesn't do by default. It's actually a good source of feedback on the kinds of things addon developers need from our APIs but aren't yet getting.
• Are add-on authors really going to split their code into modules in sane ways?
  • sort of doesn't matter. Either their code uses chrome and has to be looked at with extra care, or they import known modules to do the dangerous stuff.
  • We can model good behavior here in the core modules and documentation.
  • To some degree, this seems to be the question at the heart of major debates over how best to secure the web: can we get developers to do the right thing, or must we limit the damage from them doing the wrong thing? Huge question; I'm not throwing my hat into that ring.

Conclusions / Action Items

• API Review, well documented that can be reviewed, gather questions and meet again
  • exposed API over implementation
  • low level APIs may also be part of this (not intended to be used but they are)