Browser extensions are kernel modules for browsers(composition.al)
composition.al
Browser extensions are kernel modules for browsers
http://composition.al/blog/2015/02/27/browser-extensions-are-kernel-modules-for-browsers/index.html
4 comments
(Full disclosure - I'm an engineer that's working on multi-process Firefox).
> Add-ons come in two flavors, "old" and "new" (Jetpack). This feature is only available to "old" add-ons. The direction with Firefox has been to narrow what add-ons can do.
This is false.
SDK (Jetpack) add-ons can do everything that "old" add-ons can do. The SDK just offers nicer APIs to allow add-on authors to do common things, and adds a layer to help protect add-on authors against changes in Firefox's code-base (the SDK has very strict deprecation policies, for example). Another advantage of SDK add-ons is that, if all goes well, very few (if any) SDK-based add-ons will need to be changed in order to work in multi-process Firefox. The SDK API layer will change to accommodate multi-process, and SDK-based add-ons should "just work".
js-ctypes, which this blog post talks about, is very much accessible from SDK-based add-ons[1]. SDK-based add-ons can also get direct access to the same old-style XPCOM components that power "old" add-ons[2].
Nothing about the SDK makes those add-ons weaker - if anything, it makes them more resilient to change.
[1]: Here's a simple SDK add-on I wrote to quickly crash the selected tab in multi-process Firefox: https://github.com/mikeconley/tab-crasher It uses js-ctypes to dereference a null pointer and segfault the content process.
[2]: https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_AP... - but note the "unstable" header, since the interfaces for these components are not frozen, which makes add-ons that use them more prone to incompatibility across Firefox versions.
> Add-ons come in two flavors, "old" and "new" (Jetpack). This feature is only available to "old" add-ons. The direction with Firefox has been to narrow what add-ons can do.
This is false.
SDK (Jetpack) add-ons can do everything that "old" add-ons can do. The SDK just offers nicer APIs to allow add-on authors to do common things, and adds a layer to help protect add-on authors against changes in Firefox's code-base (the SDK has very strict deprecation policies, for example). Another advantage of SDK add-ons is that, if all goes well, very few (if any) SDK-based add-ons will need to be changed in order to work in multi-process Firefox. The SDK API layer will change to accommodate multi-process, and SDK-based add-ons should "just work".
js-ctypes, which this blog post talks about, is very much accessible from SDK-based add-ons[1]. SDK-based add-ons can also get direct access to the same old-style XPCOM components that power "old" add-ons[2].
Nothing about the SDK makes those add-ons weaker - if anything, it makes them more resilient to change.
[1]: Here's a simple SDK add-on I wrote to quickly crash the selected tab in multi-process Firefox: https://github.com/mikeconley/tab-crasher It uses js-ctypes to dereference a null pointer and segfault the content process.
[2]: https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_AP... - but note the "unstable" header, since the interfaces for these components are not frozen, which makes add-ons that use them more prone to incompatibility across Firefox versions.
I didn't think that "Cu.import("resource://gre/modules/ctypes.jsm")" was allowed in a Firefox add-on.
This is bad. Add-ons should not be allowed that much power. Especially since Wips has been buying up add-ons and putting in adware and spyware.[1][2][3] It looks like if you have the right connections, you can get malware approved into Firefox.
[1] https://addons.mozilla.org/en-US/firefox/addon/blocksite/ [2] http://forums.mozillazine.org/viewtopic.php?f=38&t=2737553 [3] http://www.howtogeek.com/180175/warning-your-browser-extensi...
This is bad. Add-ons should not be allowed that much power. Especially since Wips has been buying up add-ons and putting in adware and spyware.[1][2][3] It looks like if you have the right connections, you can get malware approved into Firefox.
[1] https://addons.mozilla.org/en-US/firefox/addon/blocksite/ [2] http://forums.mozillazine.org/viewtopic.php?f=38&t=2737553 [3] http://www.howtogeek.com/180175/warning-your-browser-extensi...
That blocksite looks pretty annoying, but according to our Add-on Dev Relations Lead (jorgev), since the tracking in blocksite is "opt in", it doesn't actually violate any of the AMO policies.
Note that I haven't actually installed the add-on or looked at the source[1], but just echoing what I'm reading in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903799
"Add-ons should not be allowed that much power" - this is tricky. We want add-ons to be powerful enough that users can customize Firefox to their liking down to the tiniest detail. And yet, we want to make sure that the add-ons are not doing completely evil things to your machine.
Our solution to that problem is code review and static analysis of add-ons that are submitted to AMO. For add-ons that you install outside of AMO... well, you're on your own there.
It's tricky. We do very much want to make the browser safer for our users, and eliminating evil add-ons is high on our list of priorities, but there's a lot of stop energy put against our solutions[2].
I'm not in charge of add-ons, but I the predicament is clear. Add-on authors want the power to make the browser do amazing things. Users want add-ons to do amazing things. Bad actors want add-ons to do evil things. We want to protect the user, but we also want to respect the user's right to do or install whatever they'd like on their machines.
It's a fine balance.
[1]: Which is something our AMO editors do - they review the source of all add-ons that go up to AMO.
[2]: https://blog.mozilla.org/addons/2015/02/10/extension-signing... is one solution we're going after. Check out the comments for some of the fors and againsts.
Note that I haven't actually installed the add-on or looked at the source[1], but just echoing what I'm reading in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903799
"Add-ons should not be allowed that much power" - this is tricky. We want add-ons to be powerful enough that users can customize Firefox to their liking down to the tiniest detail. And yet, we want to make sure that the add-ons are not doing completely evil things to your machine.
Our solution to that problem is code review and static analysis of add-ons that are submitted to AMO. For add-ons that you install outside of AMO... well, you're on your own there.
It's tricky. We do very much want to make the browser safer for our users, and eliminating evil add-ons is high on our list of priorities, but there's a lot of stop energy put against our solutions[2].
I'm not in charge of add-ons, but I the predicament is clear. Add-on authors want the power to make the browser do amazing things. Users want add-ons to do amazing things. Bad actors want add-ons to do evil things. We want to protect the user, but we also want to respect the user's right to do or install whatever they'd like on their machines.
It's a fine balance.
[1]: Which is something our AMO editors do - they review the source of all add-ons that go up to AMO.
[2]: https://blog.mozilla.org/addons/2015/02/10/extension-signing... is one solution we're going after. Check out the comments for some of the fors and againsts.
"According to our Add-on Dev Relations Lead (jorgev), since the tracking in blocksite is "opt in", it doesn't actually violate any of the AMO policies."
I know, but it says something about the Mozilla Foundation that they let that through.
I know, but it says something about the Mozilla Foundation that they let that through.
It says that they value their user's freedom? Including the freedom to apply footguns to themselves if they are clearly told that they are dealing with a footgun?
Also note that spying on the user can be done without system-level access. Since addons generally are allowed to do arbitrary XHRs anyway, so they can just record in-browser data and send it via XHR. No access to the filesystem needed. So this issue is somewhat orthogonal to access to the rest of the system, besides the aspect that a malicious addon can do more damage that way. It can still be malicious when restricted to just the browser.
Also note that spying on the user can be done without system-level access. Since addons generally are allowed to do arbitrary XHRs anyway, so they can just record in-browser data and send it via XHR. No access to the filesystem needed. So this issue is somewhat orthogonal to access to the rest of the system, besides the aspect that a malicious addon can do more damage that way. It can still be malicious when restricted to just the browser.
I have both Chrome and Chrome Canary (beta version of Chrome) installed. On Chrome I install only a few extensions I trust (e.g. LastPass, Chromecast) and use that for personal browsing. Canary is overloaded with lots of useful developer extensions that tend to have the scary "read and change all your data on the websites you visit" permission and use that for development only so I don't need to trust those extensions.
I don't think they're meant to be. If you can do something malicious with this currently, it's probably a bug or design flaw, and would likely be changed in later releases after it was pointed out.
This is the difference between NPAPI and PPAPI in Chrome, for example: while both are methods for writing native code and having it execute in the browser, NPAPI is like kernel extensions (you get whatever privileges the browser itself gets), while PPAPI puts you in the same sandbox browser extensions execute in; a sandbox which is supposed to have a level of isolation only slightly less than the one webpages themselves get. It can call a few more APIs, but it should still be in "ring 3", to follow the metaphor.
This is the difference between NPAPI and PPAPI in Chrome, for example: while both are methods for writing native code and having it execute in the browser, NPAPI is like kernel extensions (you get whatever privileges the browser itself gets), while PPAPI puts you in the same sandbox browser extensions execute in; a sandbox which is supposed to have a level of isolation only slightly less than the one webpages themselves get. It can call a few more APIs, but it should still be in "ring 3", to follow the metaphor.
You're basically arguing in favor of a walled garden that is safe but can only does what the API designers deem an acceptable use.
For some users that may be sufficient so they can sleep sound at night, not worrying about potential malware.
But powerusers often have eccentric use-cases that can only be tackled in ways that API designers didn't foresee and thus require unrestricted access to, well, everything. It's not malicious by default. It's dual-use.
If you want to be in the former group, fine. But you shouldn't argue that the latter group should be denied access to their tools.
For some users that may be sufficient so they can sleep sound at night, not worrying about potential malware.
But powerusers often have eccentric use-cases that can only be tackled in ways that API designers didn't foresee and thus require unrestricted access to, well, everything. It's not malicious by default. It's dual-use.
If you want to be in the former group, fine. But you shouldn't argue that the latter group should be denied access to their tools.
What do you mean? ``If you can do something malicious''.
Browser extensions have a lot of abilities. People install browser extensions with no idea what they actually do, when content scripts in chrome extensions can scrape all your data on all sites you visit. There is no way to whitelist extensions to only some URLs and blacklist them from others.
If the browser is an OS, extensions have A LOT of abilities to avoid SAMEORIGIN policy, skirt CSP rules, and much much more.
Bottom line, if your browser is an OS, extensions can be malicious just like regular software.....whether or not you have NPAPI support or whatever else.
Browser extensions have a lot of abilities. People install browser extensions with no idea what they actually do, when content scripts in chrome extensions can scrape all your data on all sites you visit. There is no way to whitelist extensions to only some URLs and blacklist them from others.
If the browser is an OS, extensions have A LOT of abilities to avoid SAMEORIGIN policy, skirt CSP rules, and much much more.
Bottom line, if your browser is an OS, extensions can be malicious just like regular software.....whether or not you have NPAPI support or whatever else.
It depends on the browser.
In Chrome, extensions are sandboxed using similar technique as web pages are.
However, just because they are sandboxed doesn't mean they are safe. It just means they won't be able to get privileges beyond those explicitly granted to them.
Many extensions request very powerful privileges though, like the ability to read and write to web pages you visit. The browser will dutifully grant this privilege if the extension requests it and you allow it. It won't get the ability to run arbitrary native code though (unless it also requests that privilege).
In Chrome, extensions are sandboxed using similar technique as web pages are.
However, just because they are sandboxed doesn't mean they are safe. It just means they won't be able to get privileges beyond those explicitly granted to them.
Many extensions request very powerful privileges though, like the ability to read and write to web pages you visit. The browser will dutifully grant this privilege if the extension requests it and you allow it. It won't get the ability to run arbitrary native code though (unless it also requests that privilege).
off-topic: It's been a while since I visited an octopress based site! I thought it had died or something.
Add-ons come in two flavors, "old" and "new" (Jetpack). This feature is only available to "old" add-ons. The direction with Firefox has been to narrow what add-ons can do.