5 ms·

So someone found some sort of vulnerability in Angular 1, told Mozilla about it, but told them not to tell the Angular team? What is going on here?

by phs2501 10y ago

TD-Linux 10y ago
It is possible that the researcher also secretly shared the results with Google, but then nothing happened?
- pestaa 10y ago
  As claimed in the comments, Angular 1 is now community driven instead of officially supported by Google.
  - thom_nic 10y ago
    the following comment refutes that comment and says Angular 1.x is still supported by Google.
  - deleted 10y ago
    [deleted]
  - sidcool 10y ago
    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.
- vladimir-y 10y ago
  > 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.
nathancahill 10y ago
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.
- Gigablah 10y ago
  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.
AgentME 10y ago
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-with-angularjs 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.
vladimir-y 10y ago
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.
- codedokode 10y ago
  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 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.
  - AgentME 10y ago
    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.
  - vladimir-y 10y ago
    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 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.
tiglionabbit 10y ago
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.

So someone found some sort of vulnerability in Angular 1, told Mozilla about it, but told them not to tell the Angular team? What is going on here?

by phs2501 10y ago

So someone found some sort of vulnerability in Angular 1, told Mozilla about it, but told them not to tell the Angular team? What is going on here?

TD-Linux 10y ago

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

pestaa 10y ago
As claimed in the comments, Angular 1 is now community driven instead of officially supported by Google.
- thom_nic 10y ago
  the following comment refutes that comment and says Angular 1.x is still supported by Google.
- deleted 10y ago
  [deleted]
- sidcool 10y ago
  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.
vladimir-y 10y ago
> 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.

nathancahill 10y ago

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.

Gigablah 10y ago
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.

AgentME 10y ago

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-with-angularjs 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.

vladimir-y 10y ago

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.

codedokode 10y ago
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 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.
- AgentME 10y ago
  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.
- vladimir-y 10y ago
  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 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.

tiglionabbit 10y ago

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.