5 ms·

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

talmand 10y ago
I would say it's both.
dasil003 10y ago
No, that's the facile assumption to enable finger-pointing. My money is on an interaction between two legitimate design choices when considered independently.
AgentME 10y ago
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.
- codedokode 10y ago
  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.
  - mordocai 10y ago
    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.
  - bzbarsky 10y ago
    > 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.
    - mi_g 10y ago
      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 ?
      - bzbarsky 10y ago
        > 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.
  - AgentME 10y ago
    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.
  - thesmallestcat 10y ago
    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.
nathancahill 10y ago
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 10y ago
  So a vulnerability of this kind would not only affect Firefox but also Chrome and others?
  - nathancahill 10y ago
    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 10y ago
    Most likely. Angular evals stuff from the DOM. Chrome extensions share the DOM with the webpage like Firefox extensions.
    - codedokode 10y ago
      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 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 10y ago
spiznnx 10y ago
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.
- AgentME 10y ago
  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.

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

AgentME 10y ago

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.

codedokode 10y ago
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.
- mordocai 10y ago
  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.
- bzbarsky 10y ago
  > 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.
  - mi_g 10y ago
    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 ?
    - bzbarsky 10y ago
      > 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.
- AgentME 10y ago
  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.
- thesmallestcat 10y ago
  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.

nathancahill 10y ago

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 10y ago
So a vulnerability of this kind would not only affect Firefox but also Chrome and others?
- nathancahill 10y ago
  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 10y ago
  Most likely. Angular evals stuff from the DOM. Chrome extensions share the DOM with the webpage like Firefox extensions.
  - codedokode 10y ago
    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 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 10y ago

spiznnx 10y ago

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.

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