[nathancahill]

Not necessarily. JS in addons has to run in a more privileged environment to interact with the browser. However, that makes it possible to write insecure addons. In this case, Angular 1.x might contain the insecure code.

For example: arbitrary user input from a web page is passed to the addon. Angular handles it, and does "eval-like things"[0] with it. Now the attacker is running arbitrary code in a privileged environment.

[0] eval-like things is a core part of how Angular works. So the vulnerability doesn't necessarily apply to Angular 1.x in a normal web page. But it wasn't designed to be run with higher privileges.

[secmax]

So a vulnerability of this kind would not only affect Firefox but also Chrome and others?

[nathancahill]

Every browsers addon runtime is different. Firefox is working on standardizing things with it's Web Extensions API (modeled after Chromium's API). But potentially, yes.

[AgentME]

Most likely. Angular evals stuff from the DOM. Chrome extensions share the DOM with the webpage like Firefox extensions.

[codedokode]

In Chrome content scripts (the ones that are injected into a page from an extension) run in some kind of isolated mode: https://developer.chrome.com/extensions/content_scripts

Yet they have some privileges a normal script doesn't have, for example the ability to post messages to parent extension which can be exploited.

[AgentME]

They still see the same content in the DOM. The extension just has a separate javascript-wrapper around the DOM. This means that an extension will not be affected if a webpage monkey-patches a DOM method to do something else. But if a webpage places some specific text content inside an HTML element, then the extension will see that same text content! (And Angular running in the extension can still choose to recognize that content as a template and eval it.)

[the_duke]

Chromes extension APIs do not provide the level of access that Firefox APIs do.

[bzbarsky]

The topic of discussion here is Firefox webextensions, which are meant to be API-compatible with Chrome extensions and have the same security model.

[codedokode]

You can find same kind of "vulnerability" in jQuery:

    $(element).html(user input);

This will evaluate scripts in "user input". Does this mean jQuery is vulnerable? No, it just means you are doing something wrong with it.

UPD: I was wrong, jQuery inserts a script tag into DOM instead of directly calling eval() so the code above is not equivalent to eval and is another type of vulnerability.

[bzbarsky]

It will evaluate scripts with the permissions of the element being manipulated. Which in a normal webpage is the same thing as the script doing the manipulating, which means you have XSS, which is bad, yes.

In the context of an extension manipulating a web page, though, the jQuery thing you quote will evaluate the script with the permissions of the web page, not the permissions of the extension. On the other hand, doing eval() with a string from the web page will evaluate things with the permission of the extension.

So there is a pretty subtle (and irrelevant in web pages!) but important distinction between the two kinds of script injection here. In a web page they are more or less equivalent in terms of leading to XSS if you have untrusted input. But in an extension, the jQuery one is OK if your input comes from the web page itself, and the eval() version is not.

[Disclaimer: I work for Mozilla, but not on extension policy.]

[AgentME]

jQuery doesn't do that on its own by default just by the act of loading it though. Angular does.