9 ms·

Note that the Angular team is working with Mozilla and the researcher on this (see https://github.com/mozilla/addons-linter/issues/1000#issuecomment-255183470 h

Note that the Angular team is working with Mozilla and the researcher on this (see https://github.com/mozilla/addons-linter/issues/1000#issuecomment-255183470 https://github.com/mozilla/addons-linter/issues/1000#issueco...) and that NDAs are a real, if insane, thing still to this day, and there is literally no way to legally compel any party to admit to being under NDA except in a court of law. Should the researcher have told the Angular team? Yes. Should they have told the entire world? Probably no. Should Mozilla tell the world? Probably even less no. As long as the parties are talking (which they are), this is an unfinished security review on lock-down to prevent exploitation in the interrim.

andrewstuart2 10y ago
Also, let's not inundate the page with extraneous comments unless we're already part of one of the projects involved. We all have strong opinions, and the HN post has been linked in the issue, so the devs can come here to see discussion if they want it. Let's be good GH citizens. :-) Nobody benefits from the Issue ending up locked because the discussion got too off-topic.
secmax 10y ago
> As long as the parties are talking (which they are), this is an unfinished security review on lock-down to prevent exploitation in the interrim. I agree! There are a lot of Chrome extensions out there which could be affected. Immediate public disclose would be irresponsible.
- codedokode 10y ago
  This "vulnerability" is harder to exploit in Chrome because extensions in Chrome (unlike in Firefox) have their own private DOM, and settings page have isolated DOM too. If an extension uses Angular only with its private DOM there is no vulnerability. The vulnerability can be exploited only if an extension is running Angular on an untrusted page which is less likely in Chrome (but of course one should not underestimate the level of incompetency of a modern frontend developer). UPD: @bzbarsky noted that Firefox is using the same security model as Chrome so both browser extensions can be vulnerable. To exploit a vulnerability, several conditions should be met: 1) extension should inject Angular into a web page 2) attacker should be able to find a way to get from content script context into extension's background page context.
  - AgentME 10y ago
    Chrome has many many extensions which run on and modify the page DOM just like Firefox! I think it might even be reasonable to guess that around half of extensions do this.
    - codedokode 10y ago
      Modifying DOM is not enough to cause a vulnerability. In Chrome content scripts (the ones that are injected into a page from an extension) have limited privileges though there still can be the ways to exploit them.
      - AgentME 10y ago
        Chrome content scripts can have permissions to make AJAX requests to any origin. Sure, it's not a straight-ticket to getting code native execution and installing malware on your machine, but it means an exploit against an extension with wide enough permissions could harvest your email and bank info.
      - emn13 10y ago
        It's completely expected to both inject scripts into a pages DOM, and also to set up a communication channel back from the page content script to the central extension "process". It's not a rare corner case. An ad-blocking content script might want to report user-selected extra filter requests back to the main adblocker context; or it may simply want to count the number of blocked requests; or a password manager may want the ability to save new passwords; etc. Typically, you'd expect the central extension to trust messages it receives from its own content scripts, so even though there is a separation between the extension and the pages it's on, the separation is by no means a leak-proof security measure; it cannot be. You rely on each and every such extension being carefully written and having no security relevant bugs. If you think about it, it should be clear that it's practically infeasible to fix this hole. Extensions authors simply need to avoid such bugs. If angular1 somehow makes it easy for them to make mistakes when used by an extension, that's a problem.
  - bzbarsky 10y ago
- masklinn 10y ago
  Chrome extensions are less of an issue though, no? IIRC Firefox addons are significantly more powerful than Chrome extensions, so locking things down tighter makes sense anyway, a low threat on Chrome could be much higher on FF.
  - jaredsohn 10y ago
    >IIRC Firefox addons are significantly more powerful than Chrome extensions I think that is only if you use the C++ API and that this post is talking about their JavaScript API.
    - bzbarsky 10y ago
      It's possible to write Firefox extensions in JavaScript that are a lot more powerful than Chrome extensions (or webextensions, which are the Firefox equivalent of Chrome extensions) are. That capability is slowly being phased out, though.
    - masklinn 10y ago
      > I think that is only if you use the C++ API No, historical XPI addons are in JS (and XML and CSS). While they can bundle native code most don't, but they run in at the same privilege level as the browser itself (consider Firebug, which was and still is an addon).
  - AgentME 10y ago
    If a Chrome extension has permissions to an origin, then it can freely make cross-domain requests to it from any page. So if you have an extension using Angular 1.x on every page and then browse to a malicious page, then the page could contain text in the DOM that Angular evals from within the extension. That code could then make an AJAX request to any origin with your cookies, and make requests for your bank info or emails and do things like steal data or change your passwords.
    - deleted 10y ago
      [deleted]
michaelt 10y ago
NDAs are a real, if insane, thing still to this day Some of the big security bugs recently have been disclosed to big players like Google and AWS before they were publicly disclosed. If you want to retain that privilege, you need to show you can keep your mouth shut when security researchers disclose something to you - NDA or otherwise.
- barkbro 10y ago
  What's the rationale for disclosing vulnerabilities to for example Google before going public (unless the bug is in Google's software)?
  - NeutronBoy 10y ago
    Because big players can take remedial action prior to the bug being disclosed to protect users - for example, banning a specific framework from browser extensions.
    - the8472 10y ago
      That sounds like an unfair advantage over smaller competitors to me.
      - tbrownaw 10y ago
        Yes. Fair is often not optimal.
  - michaelt 10y ago
    When you release a patch, anyone who gets it can see what you changed and figure out an exploit from that. Because it's good for people to be patched /before/ that happens, some vendors give certain major customers early access to patches - so long as they maintain a proven track record of not disclosing anything about them. For example, Xen has a 'pre-disclosure list' [1] so if they have a critical security patch, Amazon, Google, Linode, Oracle, Rackspace, and several Linux distro developers [2] get the patches early. Obviously, we can debate the morality and wisdom of this policy - personally as I haven't discovered any critical security bugs, I've never faced this particular moral conundrum. [1] https://www.xenproject.org/security-policy.html https://www.xenproject.org/security-policy.html [2] http://www.securityweek.com/several-flaws-patched-xen-hypervisor http://www.securityweek.com/several-flaws-patched-xen-hyperv...
AgentME 10y ago
The mentioned vulnerability was most likely another sandbox escape. The sandbox is described as "not a defense mechanism" by the Angular team, and the sandbox was removed entirely in the 1.6 release[0]. They admit that Angular isn't secure for cases where an attacker can control the template: this case includes extensions! I'm not going to fault someone for not reporting a security issue with an already-removed feature specifically described as not a security feature. Before anyone misreads this: the sandbox being removed in 1.6 doesn't mean that Angular 1.6 is safe to use in extensions. It just means that Angular stopped pretending it was safe there. A fundamental part of Angular is evaling text from the DOM. If the DOM is controlled by an attacker, such as a webpage trying to elevate to extension privileges, then you're out of luck. Sandboxing eval is a very large and difficult task that would bloat Angular, all for a use-case that they are not interested in. Angular 1.x is the wrong tool for the job. [0] http://angularjs.blogspot.com/2016/09/angular-16-expression-sandbox-removal.html http://angularjs.blogspot.com/2016/09/angular-16-expression-...

andrewstuart2 10y ago

Also, let's not inundate the page with extraneous comments unless we're already part of one of the projects involved. We all have strong opinions, and the HN post has been linked in the issue, so the devs can come here to see discussion if they want it. Let's be good GH citizens. :-) Nobody benefits from the Issue ending up locked because the discussion got too off-topic.

secmax 10y ago

> As long as the parties are talking (which they are), this is an unfinished security review on lock-down to prevent exploitation in the interrim. I agree! There are a lot of Chrome extensions out there which could be affected. Immediate public disclose would be irresponsible.

codedokode 10y ago
This "vulnerability" is harder to exploit in Chrome because extensions in Chrome (unlike in Firefox) have their own private DOM, and settings page have isolated DOM too. If an extension uses Angular only with its private DOM there is no vulnerability. The vulnerability can be exploited only if an extension is running Angular on an untrusted page which is less likely in Chrome (but of course one should not underestimate the level of incompetency of a modern frontend developer). UPD: @bzbarsky noted that Firefox is using the same security model as Chrome so both browser extensions can be vulnerable. To exploit a vulnerability, several conditions should be met: 1) extension should inject Angular into a web page 2) attacker should be able to find a way to get from content script context into extension's background page context.
- AgentME 10y ago
  Chrome has many many extensions which run on and modify the page DOM just like Firefox! I think it might even be reasonable to guess that around half of extensions do this.
  - codedokode 10y ago
    Modifying DOM is not enough to cause a vulnerability. In Chrome content scripts (the ones that are injected into a page from an extension) have limited privileges though there still can be the ways to exploit them.
    - AgentME 10y ago
      Chrome content scripts can have permissions to make AJAX requests to any origin. Sure, it's not a straight-ticket to getting code native execution and installing malware on your machine, but it means an exploit against an extension with wide enough permissions could harvest your email and bank info.
    - emn13 10y ago
      It's completely expected to both inject scripts into a pages DOM, and also to set up a communication channel back from the page content script to the central extension "process". It's not a rare corner case. An ad-blocking content script might want to report user-selected extra filter requests back to the main adblocker context; or it may simply want to count the number of blocked requests; or a password manager may want the ability to save new passwords; etc. Typically, you'd expect the central extension to trust messages it receives from its own content scripts, so even though there is a separation between the extension and the pages it's on, the separation is by no means a leak-proof security measure; it cannot be. You rely on each and every such extension being carefully written and having no security relevant bugs. If you think about it, it should be clear that it's practically infeasible to fix this hole. Extensions authors simply need to avoid such bugs. If angular1 somehow makes it easy for them to make mistakes when used by an extension, that's a problem.
- bzbarsky 10y ago
masklinn 10y ago
Chrome extensions are less of an issue though, no? IIRC Firefox addons are significantly more powerful than Chrome extensions, so locking things down tighter makes sense anyway, a low threat on Chrome could be much higher on FF.
- jaredsohn 10y ago
  >IIRC Firefox addons are significantly more powerful than Chrome extensions I think that is only if you use the C++ API and that this post is talking about their JavaScript API.
  - bzbarsky 10y ago
    It's possible to write Firefox extensions in JavaScript that are a lot more powerful than Chrome extensions (or webextensions, which are the Firefox equivalent of Chrome extensions) are. That capability is slowly being phased out, though.
  - masklinn 10y ago
    > I think that is only if you use the C++ API No, historical XPI addons are in JS (and XML and CSS). While they can bundle native code most don't, but they run in at the same privilege level as the browser itself (consider Firebug, which was and still is an addon).
- AgentME 10y ago
  If a Chrome extension has permissions to an origin, then it can freely make cross-domain requests to it from any page. So if you have an extension using Angular 1.x on every page and then browse to a malicious page, then the page could contain text in the DOM that Angular evals from within the extension. That code could then make an AJAX request to any origin with your cookies, and make requests for your bank info or emails and do things like steal data or change your passwords.
  - deleted 10y ago
    [deleted]

michaelt 10y ago

NDAs are a real, if insane, thing still to this day Some of the big security bugs recently have been disclosed to big players like Google and AWS before they were publicly disclosed. If you want to retain that privilege, you need to show you can keep your mouth shut when security researchers disclose something to you - NDA or otherwise.

barkbro 10y ago
What's the rationale for disclosing vulnerabilities to for example Google before going public (unless the bug is in Google's software)?
- NeutronBoy 10y ago
  Because big players can take remedial action prior to the bug being disclosed to protect users - for example, banning a specific framework from browser extensions.
  - the8472 10y ago
    That sounds like an unfair advantage over smaller competitors to me.
    - tbrownaw 10y ago
      Yes. Fair is often not optimal.
- michaelt 10y ago
  When you release a patch, anyone who gets it can see what you changed and figure out an exploit from that. Because it's good for people to be patched /before/ that happens, some vendors give certain major customers early access to patches - so long as they maintain a proven track record of not disclosing anything about them. For example, Xen has a 'pre-disclosure list' [1] so if they have a critical security patch, Amazon, Google, Linode, Oracle, Rackspace, and several Linux distro developers [2] get the patches early. Obviously, we can debate the morality and wisdom of this policy - personally as I haven't discovered any critical security bugs, I've never faced this particular moral conundrum. [1] https://www.xenproject.org/security-policy.html https://www.xenproject.org/security-policy.html [2] http://www.securityweek.com/several-flaws-patched-xen-hypervisor http://www.securityweek.com/several-flaws-patched-xen-hyperv...

AgentME 10y ago

The mentioned vulnerability was most likely another sandbox escape. The sandbox is described as "not a defense mechanism" by the Angular team, and the sandbox was removed entirely in the 1.6 release[0]. They admit that Angular isn't secure for cases where an attacker can control the template: this case includes extensions! I'm not going to fault someone for not reporting a security issue with an already-removed feature specifically described as not a security feature. Before anyone misreads this: the sandbox being removed in 1.6 doesn't mean that Angular 1.6 is safe to use in extensions. It just means that Angular stopped pretending it was safe there. A fundamental part of Angular is evaling text from the DOM. If the DOM is controlled by an attacker, such as a webpage trying to elevate to extension privileges, then you're out of luck. Sandboxing eval is a very large and difficult task that would bloat Angular, all for a use-case that they are not interested in. Angular 1.x is the wrong tool for the job. [0] http://angularjs.blogspot.com/2016/09/angular-16-expression-sandbox-removal.html http://angularjs.blogspot.com/2016/09/angular-16-expression-...