Firefox extension security and Noscript

[tlu]

If you search the web, you can find lots of papers which critisize that a Mozilla extension security model is "nonexistent", e.g. this one. This document says:

Extensions can be installed by the user, either through the Add-on Manager or via a web page.They also can be installed by an external “dropper” program. Once installed, they can hide their
presence by mis-using a number of features provided by Firefox, or worse yet by “infecting” a signed and thus presumably trustworthy extension. There are many features of extensions that
make them attractive as attack vectors; their use of JavaScript allows platform-independent payload code to be easily written, they can run as a browser thread obfuscating them from anti-virus software,
and “noisy” operations such as creating a process or editing a registry key can be avoided. Once installed and properly hidden they have read/write access to the Document Object Model
(DOM) providing them with the ability to alter user-space web content. This is particularly dangerous because the browser is in an unique position to have plaintext access to sensitive user information, such
as passwords for online banking web applications or credit card numbers used for online shopping. Extensions also have access to the username/password pairs stored in Firefox's
password manager, read/write access to the file system, and access to client and server sockets. All of these features equate for the ability for a malicious extension to be
easily or even silently installed within a browser, to conceal itself from the user, display viral behavior by modifying or injecting code into other signed extensions, sniff and modify web content “on-the-fly”,
avoid detection not only by traditional polymorphism but by running within in the context of the browser, communicate to the network using presumably benign and unfiltered protocols such as
HTTP/HTTPS and rest on the plausible assumption that most users will start the browser instead of modifying the operating system to ensure that they are run.

Both documents critisize that chrome://URI is whitelisted in Noscript thus allowing any XSS injection there. As an example they mention the Update Scanner extension which renders updated content within a chrome privileged window thus allowing an XSS injection by a maliciouos site. I'm not sure if the Noscript XSS protection would cover this - and if it would, which drawbacks we would have to suffer from.

These documents were published in 2009, and I'm aware of the new Mozilla Add-on Review Process which has been implemented in the meantime (and which is probably also a reaction to this criticism, I guess). There will also be changes in Jetpack (see here and here). Nevertheless, since I'm not familiar with the Firefox internals I would be interested in Giorgio's opinion about this issue in general and the reproaches against Noscript in particular.

[Giorgio Maone]

Both documents critisize that chrome://URI is whitelisted in Noscript

Such a "critic" just shows blatant ignorance of Firefox's internals.
chrome:// URIs aren't "whitelisted" by NoScript, they're just shown as such because they cannot be prevented from running scripts in any way, because they're the URIs where the browser UI itself "lives" and run at higher privileges.

If there was a way to "block" chrome URIs, the browser would just stop working.

NoScript cannot be blamed for the Update Scanner's idiocy: if your code allows websites to inject arbitrary content in chrome context, you're opening a gaping hole in the browser's security and deserve to be hanged to the nearest tree.

Saying that "NoScript gives you a false sense of security" (as I read somewhere) because it doesn't stop the browser from working and cannot prevent you from installing vulnerable crappy software, is either stupidity or slander.

[tlu]

Giorgio, thanks a lot for your reply - much appreciated!

NoScript cannot be blamed for the Update Scanner's idiocy: if your code allows websites to inject arbitrary content in chrome context, you're opening a gaping hole in the browser's security and deserve to be hanged to the nearest tree.

And it reveals that the Add-ons Review Process is obviously not as good as it should be. IMHO, AMO shouldn't accept such extensions.

[Giorgio Maone]

Giorgio, thanks a lot for your reply - much appreciated!

NoScript cannot be blamed for the Update Scanner's idiocy: if your code allows websites to inject arbitrary content in chrome context, you're opening a gaping hole in the browser's security and deserve to be hanged to the nearest tree.

And it reveals that the Add-ons Review Process is obviously not as good as it should be. IMHO, AMO shouldn't accept such extensions.

In fact, the review process has been improved and tightened a lot during the past years, for instance:

• an automatic scanner checks for many known buggy, unsafe, and/or malicious coding patterns
• editors are all picked among expert extension developers and must audit the code of the extension, rather than just checking that it works as advertised and doesn't exhibit malicious behavior
• in case of doubt, the mandatory review performed by "ordinary" editors escalates to a super-review to be made by an AMO administratos

This doesn't mean a 100% guarantee that a malicious or buggy extension can't be published on AMO, but is significantly better than any other web-based software repository that I know (including Google's Chrome Extensions vault and Apple's Apps marketplace). BTW, notice that even though Chrome extensions are significantly less powerful than Firefox ones and therefore theoretically safer (e.g. they cannot interact with the filesystem directly), they still pose significant security risks (e.g. they can read all your passwords, perform cross-site XHR and basically XSS any web page) and undergo NO review process.

[tlu]

In fact, the review process has been improved and tightened a lot during the past years

Indeed, I had that already mentioned that in my posting.

This doesn't mean a 100% guarantee that a malicious or buggy extension can't be published on AMO,

Yes, and it seems that Update Scanner implemented security fixes in 2009 which might explain why it's still available on AMO.

but is significantly better than any other web-based software repository that I know (including Google's Chrome Extensions vault and Apple's Apps marketplace). BTW, notice that even though Chrome extensions are significantly less powerful than Firefox ones and therefore theoretically safer (e.g. they cannot interact with the filesystem directly), they still pose significant security risks (e.g. they can read all your passwords, perform cross-site XHR and basically XSS any web page) and undergo NO review process.

Interesting! And the distance to Firefox will be even bigger once Jetpack will be used in extension development. Quote from https://wiki.mozilla.org/Labs/Jetpack/Design_Guidelines:

Currently, addons can "do anything" once installed. Jetpack is being designed to restrict, isolate, and sandbox the set of capabilities it provides to improve security for users, by extending to addons only the capabilities they need, restrict access to internal implementation details of those capabilities, and make their use of those capabilities more visible to code reviewers and users.