Re: Notes on extensions.gnome.org security

["Jasper St. Pierre" <jstpierre mecheye net>]

(Just a few comments on what's currently implemented)

Obviously, this website and its goals have some parallels with the
Mozila Addons site. I have been talking to their engineers and we both
decided that doing our own thing would be best for both of us. I have
been talking to them about how "AMO" works internally: I have some
similar engineering decisions here, and precedent is always nice.

On Wed, Aug 31, 2011 at 4:32 PM, Owen Taylor <otaylor redhat com> wrote:
> The idea of a GNOME Shell extension is to let the GNOME community
> build on top of the GNOME Shell code base, to tweak, to customize, and
> to prototype new GNOME features and behaviors.
>
> GNOME Shell extensions aren't sandboxed, and sandboxing them is
> fundamentally hard because shell extensions are defined as arbitrary
> tweaks to GNOME Shell. GNOME Shell is in the position to do such
> things as add global keybindings or read screen content, thus shell
> have the same capabilities.

I think that there should at least be some attempt to try and do
limited, but important sandboxing like "you cannot write to any files
except in storage that the extension system has allocated for you",
"you are not allowed to spawn any applications", "you are not allowed
to open any sockets" or "you are not allowed to make gsettings tweaks
except out of the schemas that I give you". Unfortunately, I doubt
this is possible with the current state of gjs/gobject-introspection,
but I think it's worth investigating.

> Of course, Linux users run unsandboxed code with arbitary capabilities
> every day - applications, for example. So the security question with
> GNOME Shell extensions is not how we can do the almost impossible job
> of sandboxing them, but how we can build up layers of social, user
> interface, and technical protections to make them not an attractive
> deployment mechanism for malware.
>
> For an average user, one of the most important thing that we can do is
> to make sure that it is actively hard to install extensions from
> untrusted sources. It shouldn't be possible to simply click on a web
> page link which downloads an extensions and then be prompted to
> install it. It's been well demonstrated that no form of confirmation
> dialog or warning text provides effective protection in such cases.
>
> By instead directing the user to extensions on extensions.gnome.org we
> achieve multiple things: we can have a review process for extensions,
> rankings and reviews will direct the user to heavily tested extensions
> and away from misbehaving extensions, we will make sure that we can
> update extensions, and even remove them if security problems pop up.
>
> The "sweettooth plugin"
> ========================
>
> In general, having the interface to find and install extensions be a
> website is attractive: it is a very natural way to include social
> aspects like ratings and recommendations into the interface and allows
> the information/installation page for an extension to be directly
> linked to from an external web page.
>
> However, as noted above, simple approaches for installing extensions
> like a MIME-type handler can be dangerous since they could be used
> to provide a code download from an arbitrary location.
>
> The current approach taken is to provide a browser plugin that
> enforces an origin from extensions.gnome.org and provides the
> following methods to the website:
>
>  listExtensions()
>  getExtensionInfo()
>  installExtension()
>  setExtensionEnabled()
>  getExtensionErrors()
>
> This allows embedding an interface for mananging extensions directly
> into the website.
>
> Threat model and mitigation
> ===========================
>
> The basic danger that we want to avoid is that someone gets an
> extension installed onto their system that has malicious code in it.
>
> The most basic way that this would happen is that someone simply
> uploads an extension to the website that is malicious, and that it
> gets through the review process without anybody noticing.
>
> Mitigation:
>
>  - Require code review for all updates of an extension not just the
>   initial upload.
>  - Provide clear code review guidelines, including that an
>   extension with hard to understand or tricky code should be
>   rejected.
>  - Provide tools to let a reviewer see what has changed in an update
>   of an extension to let them focus more attention on the changed
>   part.

This is something important, but I probably won't have time to do
this. I might just steal Review Board's MyersDiff Python
implementation.

>  - Use identity in the review process, so, e.g., it's very clear
>   when an update to an extension is uploaded by someone other than
>   the original author.

Currently, an extension has to be owned by its creator, and only
he/she can upload new versions.

>  - Make it very difficult to install an unreviewed extension; it
>   should not be easy for a reviewer to try out an extension to
>   "see what it does" before they look at the code. It should not
>   be possible for a user to install an unreviewed extension from
>   the website simply by confirming a warning dialog.

I've tried very hard to close this sort of hole.

> Another possibility would be a system-level exploit of
> extensions.gnome.org allowing modification of the code or uploaded
> extensions. Other the general security measures we take for all
> gnome.org servers, there are not a lot of things we can do about
> this, a few ideas:
>
>  - Make sure that it's explicit to the user when updates to
>   extensions or new extensions are being installed. This doesn't
>   do much to directly protect the vast majority of users, but
>   should allow quick detection of "funny business" by the community
>   in general.
>
>  - Add some capability for "self-healing" to the extension update
>   mechanism. There's not much we can do if an extension once run
>   installs a back-door on the user's system, but we should be able
>   to remove known bad extensions through the update process, even
>   if the extension doesn't have proper update metadata.

I'm unsure about this -- I don't think that an update or blacklist
mechanism should touch anything that the user or a system
administrator installed themselves.

Of course, if we try to record which extensions got installed through
the website, even with just a simple

> Somewhat similarly, there is a danger if a user with commit access to
> gnome.org introduces code into the extensions.gnome.org website that
> then gets deployed on the server. Obviously, this is something we also
> need to deal with for commits to general GNOME code, but the ability
> to immediately get things installed on user's systems makes the window
> to detect problems shorter for extensions.gnome.org.
>
> Possible measures:
>
>  - Don't have automatic deployment for extensions.gnome.org changes
>   but make it a manual process.
>  - Restrict the set of users who can commit to the
>   extensions.gnome.org code module.
>
> Beyond this, the use of a browser plugin could provide the following
> dangers:
>
>  * There might be a direct hole in the browser plugin code that
>   allows arbitrary code execution.
>
>   Mitigation:
>
>   - careful code review of the plugin.
>   - check the originating web page very early in the process
>     and don't allow untrusted web sites to even call most
>     of the code in the plugin.
>
>  * By cross-site scripting techniques someone could manage to figure
>   out how to trigger installation without an explicit request
>   from the user. Similarly, a bug in the origin checking logic
>   might allow the plugin to be embedded and controlled by a
>   website other than extensions.gnome.org.
>
>   Mitigation:
>
>    - make gnome-shell show a dialog before installing an extension.
>    - make it impossible to install an unreviewed extension through
>      the mechanism that the plugin uses
>    - make it impossible to install an extension from somewhere other
>      than extensions.gnome.org via the mechanism that the plugin
>      uses.
>
>   If all that the plugin can do is say "install plugin GUID x-y-z",
>   whch that then triggers a download from https://extensions.gnome.org
>   and shows a dialog, then any exploits along this line should at
>   least be detectable to moderately sophisticated users, who will
>   hopefully then report them so they can be fixed.

Right now you pass the plugin an URL to a "manifest file", so it's not
hardcoded to seek out the URL based on extensions.gnome.org. The idea
here was that if we needed to offload the servers with the extension
data to a CDN, we wouldn't have to make the users upgrade their
distributions.

> "Websites are websites, configuration is configuration!" ?
> ==========================================================
>
> Colin Walters expressed a strong opinion to me that he was
> uncomfortable with the idea of having a GUI to install and enable
> extensions be embedded into a website. That controls on websites
> should not effect the local state of the computer, period.
>
> He said that even if the extensions installation application was
> implemented as a web page, he'd be much more comfortable if it was run
> only as an embedded web page within a dedicated application rather
> than in a general-purpose web page.
>
> While I can sympathize with this, it's a view that is accomodating the
> the mental model of sophisticated users who are able to figure things
> out in any case. For a less sophisticated user the important thing is
> making things as clear and simple as possible, to let them focus on
> what they are doing, rather than how. I think the website approach
> works well for this.

If anyone is uncomfortable with running the NPAPI plugin, you don't
have to use it. I explicitly check for a "window.SweetTooth" object
before trying to embed the plugin object, so if you want to write a
native Firefox/Epiphany/Chromium extension, or someone just wants to
provide a simple application which embeds
http://extensions.gnome.org/, I have a relatively simple API that
needs to be defined, and I will gladly help and support anybody who
wants to build one. I won't build a native browser plugin or
application myself, though.

> (Another factor here is that we want a clear separation where
> extensions are something you have to go out of your way to find;
> turning on extensions is a completely different form of customization
> than, say, changing your time zone. So, we'd have to do something like
> make the extensions application only accessible through the Alt-F2
> run dialog.)
>
> "Extensions should be packaged!" ?
> ==================================
>
> If we just treated extensions like all other code on a linux
> distribution and didn't have extensions.gnome.org, then we wouldn't
> introduce new security risks.
>
> However, this does not correspond to our overall goals for extensions:
> we want a very clear distinction between extensions and applications,
> we want extension installation to be under the control of the user
> and not the system builder, and we want to encourage a community of
> extension creation that doesn't involve an extra layer of distribution
> specific packaging.
>
> Conclusion
> ==========
>
> A model where we encourage users to download and run code that doesn't
> go through the normal GNOME channels of patch review, release and
> packaging clearly presents new security challenges. The most important
> thing we can do to address these challenges is to make sure that we
> have a review process and solid update mechanism in place. This is
> achieved by making extensions.gnome.org the central location
> for extensions.
>
> Beyond this, the security challenges posed by extensions.gnome.org are
> mostly standard ones of maintaining website and code security. Certain
> mitigation measures indentified above: in particular making the
> interfaces used by the plugin limited to installing extensions from
> extensions.gnome.org and providing explicit client-side notification
> during installation and update of extensions can provide an extra
> layer of security.
>
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>

-- 
  Jasper