It's possible that the vulnerability only effects Angular running in Firefox addons, and not the general web. Mozilla takes an aggressive stance on what they allow in vetted browser extensions, as they should.

JS in addons runs in a different, more privileged environment than normal web pages, and isn't restricted by things like same-origin (although this is improving with Firefox's new extension APIs). Any project the size of Angular is bound to have security issues when run outside of the environment it was designed for.

In other words, the vulnerability is with Firefox instead of Angular?

No, the vulnerability specifically has to do with Angular within extensions. Angular trusts the page DOM and uses eval-like functions on code within it. This is relatively fine if the DOM isn't controlled by someone else, but in cases where the DOM is controlled by someone with less permissions (ie. Angular is running in a higher-privilege extension, and the DOM is controlled by some webpage), then then an attacker can elevate their permissions by writing code into the DOM and letting Angular execute it within the extension.

Don't extensions have their own DOM (like they have in Chrome)? Why would anyone run Angular on a browser page? It would probably conflict with existing application.

It looks like Firefox extension architecture has design problems.

And I don't like the presentation. One could think that Angular is vulnerable which is not true. The vulnerability appears when it is used in a wrong way in a browser extension.

This is an issue with extensions that run code on webpage DOM. It's very popular for extensions to modify webpages. Chrome supports extensions like this too. I might even guess that more than half of extensions do this.

>Why would anyone run Angular on a browser page? It would probably conflict with existing application.

Adding additional widgets or tools directly within an existing webpage is a common thing for extensions to do. And if you're adding a lot of UI, you might want to use an existing UI library like you would on a normal webpage instead of doing all the DOM by hand. Not all UI libraries work out well for this apparently.

> Don't extensions have their own DOM

They can. They can also manipulate the page DOM.

> Why would anyone run Angular on a browser page?

Because you want to manipulate its DOM and Angular is what you're familiar with?

> It would probably conflict with existing application

Note that it would operate on the same _DOM_ but not in the same scripting environment. That is, if you have a DOM element "foo" that comes from the web page, then doing:

  foo.somePropNameIMadeUp = 5;

will set a property that is not visible to the web page, while doing:

  foo.setAttribute("id", "myId");

or:

  foo.id = "myId";

will modify the DOM in a way the web page can see.

Thanks Boris, this makes more sense.

So the risk is that an add-on would inject angular 1.x into an external web site, this web site being malicious, it modifies its own DOM, so that angular would eval expressions from this DOM within the scripting environment running at a higher privilege.

What if the malicious web site does something like <script src="resource://dumb-addon/angular.min.js"></script> ? On Firefox, i verified this loads angular into the web site, but what about the privilege level ? Will it be the original one from the page or higher ?

As a side note, doing the Chrome equivalent <script src="chrome-extension://dumb-addon/angular.min.js"></script>, the loading fails with an exception saying "chrome-extension://" is not an allowed source.

In my extension, i modified the angular.min.js file to insert this as the first line:

(typeof window!=="undefined" && window.location && window.location.href && window.location.href.startsWith("resource://my-extension/")) || (function() { throw "Library loading not allowed" })();

Basically, it throws an exception if the library is not loaded from a local "resource://" page (hopefully considered as safe since it is part of the add-on code). I verified this prevented loading angular using the <script src="resource://..."> trick or if angular was inadvertently injected using a Firefox frame-script (nsIFrameScriptLoader.loadFrameScript) and add-on sdk/page-mod or sdk/content/worker modules.

Can we consider it is safe to use angular 1.x only from local add-on panels to run the user interface ?

> What if the malicious web site does something like <script src

That will run with the website's privileges. Just like site A loading a script from site B will run it with site A's privileges.

> the loading fails with an exception saying "chrome-extension://" is not an allowed source.

Chrome extensions (and webextensions) have a way to flag particular files as "web-exposed". Ones that are not can't be loaded via the web.

Firefox has something similar for chrome:// URIs in non-webextensions, but resource:// allows loads from the web in certain contexts, which include <script> elements.

> Can we consider it is safe to use angular 1.x only from local add-on panels to run the user interface ?

I don't know the details of what the security issues reported on angular 1.x are, so I can't claim that it's safe or not safe. But at first blush, as long as angular is only interacting with the addon's own DOM, and the addon DOM never injects any text from a page DOM into itself, it _seems_ like it should be safe.

The presentation is fantastic. It proves beyond a doubt that Angular is vulnerable in the context that it claims to offer a security feature that is manifestly insecure. And I mean, they're evaling JS code in the template engine, this shouldn't be a surprise. To be clear, Angular from its inception claimed to offer "safe" templating. So this is a big deal.

Browser extensions in all browsers typically do things to the web page DOM for various reasons. I don't know how the technical details work since I've never written one, but chrome addons can certainly change things about the web page DOM.

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.

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

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.

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

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.

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.)

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

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

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.

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.]

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

No, that's the facile assumption to enable finger-pointing. My money is on an interaction between two legitimate design choices when considered independently.

Firefox wasn't designed to run Angular in an extension on webpage DOM. Angular wasn't designed to run in Firefox extensions on webpage DOM. Nether has a vulnerability, when used as designed.

It's not safe for a 3 year old to drive a car, even if there's nothing wrong with the baby or the car.

And this isn't specific to Firefox: Angular 1.x in Chrome and Safari extensions for example is similarly affected.

I would say it's both.

The vulnerability specifically has to do with Angular being used in extensions where the extension has more privileges than the webpage it's affecting. Judging by http://www.slideshare.net/x00mario/an-abusive-relationship-w..., the issue has to do with a general design feature of Angular: it runs eval-like functions on text within the page DOM. Angular simply isn't built for the page DOM is controlled by an attacker (ie. Angular is running in a higher-privilege extension, and the webpage controls the DOM and wants to inject code into the higher-privilege extension). Angular has band-aids over a few specific ways that this can be taken advantage of, but it's extremely difficult to make bullet-proof (as blacklisting strategies often are) and it's not an issue that affects regular non-extension web pages.

It's not the "some sort of vulnerability", it's a critical vulnerability in the design of the Angular v1, a long known vulnerability in fact.

This "vulnerability" can be only exploited in specific cases when Angular is used in an unintended way - for example, injected in a web page from extension context in Firefox (which is wrong anyway because it would conflict with scripts on the page).

I tried to understand whether the same is possible in Chrome - injected scripts there have less privileges and use some form of isolation - but the manual [1] doesn't give a clear answer. The injected (and exploited) content script has lower privileges than an extension but has some API methods not available to scripts on a page. For example it can send messages to an extension and it could be exploited too.

But generally Chrome extension architecture provides more isolation and looks more secure especially when extensions are written by not very experienced developers.

[1] https://developer.chrome.com/extensions/content_scripts

UPD: Firefox uses the same security model for its web extensions as Chrome so both browsers are equally vulnerable.

I was writing about problem in general, not relatively to the Firefox extensions. Someone may name that not a vulnerability, but Angular v1 makes it very easy to shoot yourself in your foot doing string based values evaluating as expressions.

Imagine a case when some front-end developer gets JSON data from the remote data source by REST, having no idea about data source origin. Then for example there is a need to apply $watch for some fields of the received JSON object. Lets assume some of the fields contain JS code (for now it would be a sandbox bypassing snippet, but since v1.6 seems it can be plain JS with no obfuscations). As a result XSS happens. They would better disable string based expressions evaluating for the listed methods https://docs.angularjs.org/guide/security and allow only passing function as an argument, then it would be clear for developers that data sanitizing is up to developer and it's supposed to be implemented in the custom functions. But design issue would still exist.

Chrome extensions running in webpages share the DOM with the webpage. That's how they make modifications to the webpage.

They have their own javascript-wrappers around the DOM, so an extension is not vulnerable to a webpage overwriting DOM methods, but obviously the DOM still has the same content visible in it, and this can't protect extensions from using libraries which eval content within the DOM.

It is possible that the researcher also secretly shared the results with Google, but then nothing happened?

> nothing happened

On the contrary - they reacted removing sandbox completely giving up handling sandbox bypassing snippets, the problem is in the design of the framework and it can't be just fixed.

As claimed in the comments, Angular 1 is now community driven instead of officially supported by Google.

Not true. Google has diverged development of Angular 1 and 2. Angular 1 was initially developed with designers in mind, but it caught on with developers. They developed Angular 2 with developers in mind. Angular 2 is different from 1 in many respects. I don't see Google dropping Angular 1 support anytime soon.

the following comment refutes that comment and says Angular 1.x is still supported by Google.

The explanation is in the issue thread now. If you have Angular running in an extension, if it sees Angular tags in the page you're viewing, it could execute them with the elevated permissions of the extension instead of the permissions of the page.