Paging @wagnerand, if Google is still supporting this version and it's fixed this seems like we're being too aggressive.

My information is that Google stopped supporting angular 1.x months ago. It is now a community driven project. Also, we have been made aware of exploits that are not part of the presentation.

@tofumatt @wagnerand I have never read anything from the team that says they are no longer supporting 1.x. Here are some posts that I found that have quotes from the Google team regarding support:

http://stackoverflow.com/questions/37037251/angularjs-1-x-support-lifecycle
https://www.quora.com/When-Angular-1-X-will-become-deprecated

Looking at the GitHub repo shows that the top 3 contributors over the past month are all from the Angular team themselves still:

https://github.com/angular/angular.js/pulse/monthly

Angular 2 was only released 1 month ago so already dropping support for Angular 1.x seems too aggressive to me.

I agree with @kspearrin.

I know @wagnerand has mentioned other exploits (seemingly) not public; have you disclosed them to the Angular team so they can fix them? Seems like this is a bit too aggressive.

Unfortunately, we were not able to report them to angular as the security researcher who found them asked us to not share them.
The underlying issue is a design specific issue though. Even if public exploits can be fixed, there will most probably be always another way to circumvent the patches.

Ouch, that sounds brutal that they wouldn't share the security exploits with the team 😢

Okay, we should update the docs with this extra info then; even if we can't disclose the vulnerability we can say that we know of one and don't feel comfortable with people running angular in webextensions.

Is there any possible way for us to get around this ban? Are all parts of Angular affected? Organizations with large extension projects cannot react to new versions so quickly (especially the large overhaul that Angular 2 is). It would seem to me that you are going to block out a large number of developers from distributing their extensions on Firefox since using Angular 1.x is still being encouraged by Chrome in their web extension documentation today.

Follow-up edit since it seems this has blown up:

I want to clarify that I am not suggesting that we be allowed to publish the extension if it is indeed affected by some Angular vulnerability. Since there are no details about the mentioned vulnerability, I am suggesting that if it does not affect the parts of the framework that we are using, we may be granted some special exemption and get around the blanket ban.

It's very disturbing that the vulnerabilities are not being reported to the Angular team. That's an important part of responsible disclosure...

@joepie91 But might be a legal issue, if the researcher only released the information to the FF team under a strict non-disclosure agreement.

There’s nothing they can do about it in such a case (but the researcher seems shady for not reporting it to the source indeed)

Angular is removing the expression sandbox as of 1.6. They are doing that because the sandbox (while never intended to be used for security) was being used for security. Researchers kept showing over and over that the sandbox was not secure enough. Eventually, they just removed the sandbox. Personally, I feel like the sandbox (while not perfect) was actually pretty effective. I actually submitted the last known sandbox escape for versions 1.5 which seemed to lead to the removal of the sandbox. I now wish I hadn't. http://angularjs.blogspot.com/2016/09/angular-16-expression-sandbox-removal.html , angular/angular.js#14939

• Google still supports 1.x.
• Even if they didn't, does Mozilla suddenly have a beef with community-driven projects???
• "There's a super-secret vulnerability in one the most popular web frameworks ever, seriously, I can't tell you what it is but it's totally there" doesn't pass the smell test.

Hi. I'm working on security for Angular 1. We've reached out to Mozilla and the security researcher on this and are trying to clarify what's going on. We believe this is likely a misunderstanding. Please stay tuned, we'll comment on this issue.

@justjanne If that happened (and that's highly speculative at this point), that seems like the moment for Mozilla to take a stand and say "no, we will not sign an NDA on this". NDAs for vulnerability disclosure (other than embargoes from the vendor themselves) are highly unusual, and for very good reason...

@ihsw This is probably not the right venue for a lengthy discussion about this, but the idea of "responsible disclosure" is to get things fixed as quickly as possible with as little impact as possible. While full disclosure is sometimes the answer to that (particularly with troublesome vendors), it would be wrong to equate "full disclosure" and "responsible disclosure" as if they are one and the same thing.

My understanding is that Angular runs eval-like functions on the page DOM. When Angular is run from within an extension using a DOM controlled by the webpage, then the webpage can write code into its own DOM which Angular from within the extension will execute with its extension privileges. Making a general secure sandbox for this type of case is very difficult (see how complicated Google Caja is; is the Angular team going to go through that much effort purely to make Angular work securely in extensions?). They've probably put band-aids around a few specific escapes, but as long as eval is used on arbitrary text from the page DOM controlled by an attacker, the root cause isn't fixed and there's probably many escapes more possible.

The fact that they've removed the sandboxing entirely in 1.6 makes it seem like they've come to the same conclusion, and decided to stop giving the appearance they've solved the issue. Angular 1.x fundamentally isn't designed for running in (higher-privileged) extensions on a shared page DOM.

@wagnerand

It is now a community driven project.

Please clarify one thing especially: all libs and frameworks, driven by community, are enough reason for ban, right?

You have a responsibility to the people to share the vulnerability with the Angular team. Following the prohibition of the security researcher, right or wrong, at the expense of sharing information that could protect people and companies from these vulnerabilities, really doesn't seem right at all. Ultimately, it's incorrect to justify it by saying "researcher told me to do it", you have to take responsibility for your choice not to share it. So I don't think it works to simply deflect the matter to it having being already decided by someone else. There are likely issues bearing on the sharing of this information, that you could contributed to discussing in order to work out the best way forward. To silence that discussion from happening, because someone told you not to -- doesn't seem to be in everyone's benefit here.

[Casual note this was posted on HackerNews, therefore the comment influx]

edit: updated link to not point to the nintendo switch hacker news post 🎉

@dosaygo-coder-0 Many NDAs even prohibit discussing that you are under an NDA in the first place. There has been nothing confirmed yet regarding why Mozilla says they can’t discuss the issue or tell anyone about it yet, so we shouldn’t jump to conclusions just yet.

@dosaygo-coder-0

You have a responsibility to the people to share the vulnerability with the Angular team.

The Angular team already decided that the fundamental issues of Angular within extensions were not in scope of the project: the sandbox was specifically described as not a defense mechanism and was entirely removed in 1.6.

[Thanks @mooman219 - DevRel is aware and will pay attention to the HN thread. Also emailing some folks right now and flagging this for followup next week once I get back from a conference.]

@mooman219 Your hackernews link goes to the nintendo switch discussion not the firefox one

Correct Hacker News discussion

This is ridiculous. Even if there is a large security vulnerability, the fact that a dev finds this out the hard way is counterproductive.

Mozilla should support Angular by disclosing vulnerabilities to the Angular team ASAP

@justjanne indeed we shouldn't jump to conclusions. No one knows if an NDA is the excuse here or not. So far the excuse is "researcher said so." So no need to assume NDA for now.

@agentme assuming Angular team might not need to know it doesn't seem like a strong reason to prevent you from sharing it. Maybe you don't understand the extension scope view of that team, maybe you don't understand the vulnerabilities. So how can you say they don't need it for sure? And if there's a small chance, you must share it.

Way safer to discuss everything with the relevant people, and share it with them, and decide together, than assuming you know what's best before doing that and everything's clear. Just a general point.

With @whitef0x0 agree. I think the important point here is that in the absence of total clarity, one shouldn't assume there's no need to share them. Keeping Angular team in the dark isn't going to help anyone get secured. It's reasonable to assume the vulnerabilities would be useful to them, and they are the ones who can fix it, so it must be shared, and there doesn't seem a good reason to not share them. "NDA" or "researcher" are just excuses that limit discussion and deflect responsibility, delaying the actual result of a fix from happening.

@dosaygo-coder-0 The vulnerability was within a feature specifically described as not a security feature and was already removed in 1.6.

Angular runs eval on text in the page DOM. When the DOM is controlled by someone with lower privileges (ie. Angular is running in a higher-privileged extension with the DOM controlled by a webpage), then they can elevate their privileges by placing code in the DOM and letting Angular execute it within the extension.

Angular <1.6 blacklisted specific ways to do this, but it was not nearly complete. Fully securing this would take a ton of effort and would heavily bloat the size of Angular. The vulnerability mentioned in #1000 (comment) was most likely another way around this blacklist. The blacklist was not guaranteed or even intended to be foolproof: it's described here as "not a defense mechanism". The blacklist was entirely removed in 1.6. They admit that the sandbox blacklist was never enough to properly secure Angular in contexts such as extensions where an attacker can insert templates; from that post, it's apparent they're not interested in knowing more ways it could have been bypassed.

I'm on the incoming end of most security bug submissions to Mozilla. We don't sign NDAs to get bug info. Besides, that would involve the lawyers and takes forever. We do sometimes agree to embargo a bug, especially if it involves multiple products (not withholding from those products, but so they have time to patch also). We definitely would not agree to withhold a vulnerability from the maintainers of an upstream library if that's where it needs to be patched.

@dveditz so how come this was not forwarded to angular team ?

@petebacondarwin - Any update on progress made here? We have been waiting for weeks now, and while long term we plan to move to Angular 2.0, it is definitely not couple of days work to move there. So we are depending on your interaction and making Angular 1.5.* go ahead and get white-listed again. Thank you very much!

Waiting here for the final call too, with a few million users depending on that decision.

I will have an update on changes to our patch if necessary by the close of US daytime today.

Hello everyone, on behalf of the Angular team I'm posting an update after our meeting with the Mozilla folks today.

These were the key take aways from the meeting:

• Mozilla folks agreed that to the change fix(security): do not auto-bootstrap when loaded from an extension. angular/angular.js#15346 we implemented 3 weeks ago is a good workaround for the problem identified as "Firefox script loader can be tricked into loading angular.js into websites from Firefox addons, where once angular autobootstraps bad things could happen"
  • Mozilla security folks requested a few minor tweaks to the implementation that we already implemented as feat(security): explicitly whitelist URL schemes for bootstrap. angular/angular.js#15427 right after our meeting
• Mozilla folks expressed concerns about the use case where addons inject Angular into web pages via a content script. The number of addons that do this is currently limited.
  • Angular team believes that this is an anti-pattern due to concerns about the impact of loading Angular into a foreign environment that could cause various unexpected collisions. We recommended that such addons are banned until the day when this kind of usage is officially supported by Angular - this is however currently not on our roadmap.
• No other significant concerns were brought to our attention by the Mozilla team.
  • Angular team committed to release version 1.5.9 that will contain the two pull requests mentioned above tomorrow (Nov 24).
  • Mozilla team committed to lifting the ban for all version of Angular >=1.5.9 effective Dec 1, 2016 when they'll push an update to their addon linting infrastructure.

I'm hopeful that after weeks of delays, this issue will be finally resolved on December 1, 2016. In the meantime, happy Thanksgiving to those observing Thanksgiving tomorrow! 🦃

@deadsquid please confirm this agreement as the Mozilla representative. If I accidentally got anything wrong, please point it out. Thank you!

Thanks a lot @IgorMinar and Angular team for resolving it with Mozilla team. Happy ThanksGiving!

@IgorMinar This is very good news, I already made a calendar entry for a december 1st release for our team 💯
@deadsquid Please confirm 👍

We have just released 1.5.9 containing the security patches requested by Mozilla. It is available right now on npm and code.angularjs.org; it will be available on the Google CDN tomorrow.

We are also releasing 1.6.0-rc.2 containing the same patches later today.

We expect that Mozilla will lift its ban on add-ons built with Angular 1.5.9+ by December 1st.

Thanks @petebacondarwin , @deadsquid, @IgorMinar and @mprobst + @Rob--W - for working together. 1.5.9 is great news!

Howdy folks,

We should have a review policy update out early next week and a push to the linter by end-of-day (Pacific time) on Dec 1st, per @IgorMinar's post above.

It's important to note a couple things:

• If your add-on uses Angular, you will need to include unmodified, non-repackaged versions. Add-ons that incorporate modified versions will be rejected.
• We'll be reaching out to affected add-on developers to update their extension to incorporate the patched version of Angular. Additional changes may be requested, and we'd ask that you keep an eye out for email from us and address any changes as quickly as possible.

Thanks again to the Angular team for working through the issues discovered with us, and for incorporating the additional changes.

(edited to let add-on developers know that we may ask for changes other than just upgrading)

Just a note that this is scheduled to be deployed Dec 1st as per the AMO deployment schedule calendar: https://calendar.google.com/calendar/embed?src=mozilla.com_lr5jsh38i6dmr72uu4d1nv7dcc%40group.calendar.google.com

Bypassed the fix, wrote @petebacondarwin :)

Aw man!

@cure53 - we have landed fixes for the bypasses in master, 1.6 and 1.5 branches. See:

• angular/angular.js@ebe9005
• angular/angular.js@a649758

@petebacondarwin What 1.5.x version can we target for this fix?

@petebacondarwin LGTM, @masatokinugawa what do you think?

@kspearrin - we were hoping not to do any more 1.5.x releases, but I guess we might have to make an exception in this case. The difficulty is that we must get 1.5.x commits synced into Google before we can release so it will take a little longer. The version number will be 1.5.12

@petebacondarwin If 1.6.x is the only upgrade path that is fine, we'll just have to make that move sooner than originally planned. I was just under the impression you would be releasing 1.5.x as well since you mentioned the change was applied in that branch as well.

I found it still can be bypassed on a specific situation.
@petebacondarwin Shall I report details to pete@ba[...]com?

This issue is closed and emails quite a lot of people in the mozilla add-ons team. If you have other issues could you please report them to the angular team using their reporting system. Thanks.