
Angular 1.x Banned from Firefox Addons - secmax
https://github.com/mozilla/addons-linter/issues/1000
======
dancek
Many commenters here seem to be completely misunderstanding the situation.

Browser extensions are really dangerous; if you need to keep your machine
secure, you shouldn't use any IMHO. By definition, browser extensions need to
be able to access things such as page content. What would stop someone from
writing a extension that captures your bank credentials? _Nothing._

Obviously no security-conscious user is going to install a bank credential
stealing extension. But what about bugs in extensions? If a buggy extension
can be made to execute arbitrary code, it is as dangerous as a malicious
extension (if the arbitrary code execution works in the same circumstances).

Angular 1.x basically runs eval on DOM content. That's how it works, it's not
a vulnerability in normal use. You make a web page using Angular, and possibly
the user has a way to eval arbitrary JS code through Angular, but then they
have the developer console so they can run arbitrary code anyway.

With browser extensions it's different. The extension is from one source and
runs with one set of privileges, and the page comes from someone else and has
less privileges. Now if anything from the page can be eval'd in the extension,
that's privilege escalation. Someone creating a site can run malicious content
as a browser extension.

It's probably possible to sanitize all external inputs used in the browser
extension such that privilege escalation isn't possible, but the Angular team
has tried hard with their sandbox solution with no success. Extension
developers will hardly do much better, so it makes sense for Mozilla to ban
the whole library.

Angular wasn't designed for browser extensions.

WRT the security researcher and Mozilla not disclosing other known sandbox
vulnerabilities, that's missing the point (but an interesting discussion in
itself).

~~~
Nitramp
Hey. I work on security for Angular.

> It's probably possible to sanitize all external inputs used in the browser
> extension such that privilege escalation isn't possible, but the Angular
> team has tried hard with their sandbox solution with no success. Extension
> developers will hardly do much better, so it makes sense for Mozilla to ban
> the whole library.

AngularJS runs expressions that are in your page's HTML when it initializes
(or when you explicitly call angular.bootstrap on an element), but only on the
page where it is loaded. If an extension uses Angular within the extension,
that's perfectly fine, security wise. Unless the developer explicitly requests
it, pages visited cannot move code into an extension's context (which would be
dangerous in any case, Angular or not).

Even when the developer explicitly moves data from a web page into the
extension context, this does not cause a security issue, even when the data
ends up in the DOM. Once loaded, Angular does not revisit the DOM to run
expressions in it (otherwise all Angular pages would be compromised). Care has
to be taken when using things like ng-bind-html, but the security profile for
an extension is the same as a regular web page here. With Angular's $sce
service and automatic escaping/sanitizing, it's actually reasonably easy to
write safe web applications that properly escape user input.

All of this is unrelated to the expression sandbox. The sandbox was never
intended to be a security feature, but rather a feature to keep developers
from shooting into their own foot (e.g. by creating global variables). It was
considered to be defense-in-depth mechanism for a while, but it turns out it
is at best misleading for users who believe it protects them. That is why we
removed it.

~~~
dancek
Thanks for the reply. I mistook the sandbox to be related to $sce. It's been a
while since I last coded Angular.

So you're saying that Mozilla is mistaken in their decision, and the only way
for page content to be eval'd with extension privileges is if the developer
was careless with ng-bind-html or $compile?

~~~
Nitramp
It's a bit more complicated.

Yes, Angular itself is fine, and there's no problem with escaping or eval'ing
per se.

However there is a corner condition in which Angular being present in an
extension might weaken some security measures. It requires multiple issues to
happen together, including the victim page being vulnerable in the first
place. I'm actually not sure if that is the issue that Mozilla was thinking
about, but it is a problem. We will put some defense in depth into Angular to
mitigate this, but I believe it's a general issue with how extensions are
handled, not limited to Angular.

Sorry for being a bit vague, but no patch has been released yet.

~~~
willvarfar
thx for the update

------
TheRealPomax
Note that the Angular team is working with Mozilla and the researcher on this
(see [https://github.com/mozilla/addons-
linter/issues/1000#issueco...](https://github.com/mozilla/addons-
linter/issues/1000#issuecomment-255183470)) 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.

~~~
secmax
> 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
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
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
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
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.

------
DannyBee
So, there's so many problems with this i don't know where to begin. Since
folks have already noted the "not notifying google" issue, let me point out
another:

Prior to banning, i can find literally no discussion or details about this
being about to happen (IE no notice), pretty much ever.

You can see it was initially noted here: [https://github.com/mozilla/addons-
linter/commit/86f4dfb44355...](https://github.com/mozilla/addons-
linter/commit/86f4dfb44355a7de68d87cf72aa678086894dac7)

I can find no discussion around it (maybe it's there but i'm missing it? I
looked in a lot of places).

You can see it fixed an issue to "warn third party developers of things we
banned/don't advise", but there's nothing about initially banning anything
there, and it was added _with an initial ban list containing angular_. I would
have expected a page added, then a ban discussed, then a ban added. or
something.

In fact, the details of the ban changed ([https://github.com/mozilla/addons-
linter/commit/2dcc2226e2ec...](https://github.com/mozilla/addons-
linter/commit/2dcc2226e2ec9dea65708b0a1cc97a9cd593d82d)) repeatedly without
notice either.

This seems really bad. I would have expected, at the very least, a heads up to
extension developers or something or even _a more public notice when it
happened_ so that some discussion could be had about it.

Instead, it looks like the only way you would have found out about it is by
trying to lint an extension and see it banned (IE after you developed it), or
somehow random browsing of doc pages mozilla has.

~~~
TAForObvReasons
> Instead, it looks like the only way you would have found out about it is by
> trying to lint an extension and see it banned (IE after you developed it)

It's one of the big dangers of a "walled garden": you are subject to the whims
of the arbiter.

~~~
ben_jones
I wonder if any business-critical apps stopped working because of this?

------
Animats
Using big external libraries in Firefox add-ons used to be totally prohibited.
Jquery used to be prohibited outright. It's an undesirable practice. Add-ons
operate at a higher privilege level than web pages. The low-quality webcrap
that can be tolerated on a web page has no place in a privileged add-on.

~~~
omouse
Agreed and this is why React has been given a pass I think, because it's only
for display purposes.

~~~
vmasto
Really it doesn't matter if it's for display purposes or not. It all boils
down to implementation. I can make a view library riddled with XSS vulns in
very little time.

------
phs2501
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
It is possible that the researcher also secretly shared the results with
Google, but then nothing happened?

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

~~~
sidcool
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.

------
encoderer
Bitwarden is a password manager? And their engineer is asking, after being
told a hint of serious security issues in their framework, to just forget
about it and let them publish?

That's an interesting approach.

~~~
xxkylexx
No, the engineer is asking for more information so that he can determine if
the application is truly affected by some unpublished Angular vulnerability or
if Mozilla is just being too aggressive with their ban hammer because someone
said "Angular 1.x was no longer being officially supported", which is false.

~~~
martey
I think encoderer was referring to [https://github.com/mozilla/addons-
linter/issues/1000#issueco...](https://github.com/mozilla/addons-
linter/issues/1000#issuecomment-255096658), where the engineer asks, "Is there
any possible way for us to get around this ban?"

~~~
sparky_z
Followed up immediately with "Are all parts of Angular affected?" The
charitable interpretation is that he is asking "is there a safe subset of
Angular that we can use instead of a blanket ban?".

~~~
encoderer
Yeah that's a fair (and more charitable) way to read that. But it's also not
that clear. He spends a lot of time worrying about how much time they've spent
on their extension.

Why no "woah, our other angular apps could be affected, is there any safe
subset of angular 1?"

There aren't many products where security matters THAT much. I'd hope that the
people working on password managers have a total security first mindset.

------
ggregoire
The banned version is the 1.5.8. Could the following announce be related?

Angular 1.6 - Expression Sandbox Removal:
[https://angularjs.blogspot.mx/2016/09/angular-16-expression-...](https://angularjs.blogspot.mx/2016/09/angular-16-expression-
sandbox-removal.html)

~~~
wnevets
removing the sandbox just removes the illusion of being protected.

~~~
vladimir-y
Correct, now it should be clear for all that Angular v1 is dangerous thing by
design and it should not be used at all. Most likely a lot of not very
experienced developers do for example $watch on value provided by the user
input and that's a 100% XSS vulnerability since $watch does evaluate value if
that was a string. And $watch is just a one example, there is a list of
methods that do expressions evaluation.

~~~
bzbarsky
Note that in the context of a browser extension an "XSS vulnerability" means
"a web page just got to run code with the extension's privileges"....

[Disclaimer: I work for Mozilla.]

~~~
vladimir-y
I guess extension's privileges means more privileges than a regular web page
has (accessing file system for example?), if so then it's even more dramatic.

~~~
bzbarsky
Right. Extensions have more privileges than normal web pages.

For the specific case here (webextensions), the extension asks for a list of
permissions at install time, so which privileges it has, exactly, depends on
the extension.
[https://developer.chrome.com/extensions/declare_permissions](https://developer.chrome.com/extensions/declare_permissions)
has documentation on what the various permissions you can request are.

------
gima
Ugh, this kind of thing gets my blood boiling. It was clearly said that _a
security researcher_ disallowed Mozilla from reporting the vulnerability
forward. It's the individual to blame, not Mozilla.

In any case Personally I wouldn't want to run a large priviledged application
as a browser extension when it's interacting with random webpages AND handling
my security credentials. Too much attack surface.

~~~
nchelluri
Curious, do you use a password wallet/manager application, and if so how do
you get passwords out of it and into the browser? I'd like to know if there's
a better solution. (I use a browser extension.)

~~~
nathancahill
I think his point is that running the entire Angular 1.x framework to power a
browser extension gives a large attack surface.

~~~
gima
Yes. And to answer nchelluri's question: Auto-typing, though I believe that's
available only on desktop operating systems.

~~~
nixos
> though I believe that's available only on desktop operating systems.

And on Android (where you set up the password manager as a custom keyboard),
and possibly an iPhone

------
smrtinsert
> My information is that Google stopped supporting angular 1.x months ago. It
> is now a community driven project.

I totally missed this - was there a notice of this posted somewhere?

~~~
wnevets
Yeah that doesn't sound true at all.

~~~
mlent
Was recently at an angular conference -- they said they would continue to
support it until the _majority_ of the community had made the switch. That's
so far from happening, I imagine they'll be supporting it for years.

~~~
sgc
At least until they get tired and change their minds, which may not take that
long.

~~~
coding123
Even if that did, there might be a community that pops up to take on the
burden instead of G.

------
hannob
I'm not sure if this is the same case, but I assume it is: if you're wondering
why the researcher doesn't want to share the vuln listen to this talk:
[https://www.youtube.com/watch?v=U4e0Remq1WQ](https://www.youtube.com/watch?v=U4e0Remq1WQ)

Roughly at 41:30 he explains why he doesn't want to disclose the vuln. The
tl;dr is he thinks the sandbox is broken beyond repair and whatever fix they
come up he can create another bypass for the sandbox. But he doesn't want to
do this all the time and he needs his vuln as a poc to show to customers if
they abuse the sandbox.

~~~
icecube
That was a good talk. I highly recommend watching the entire video.

------
laurent123456
That doesn't make much sense. If there's a vulnerability in Angular, doesn't
it mean that there's a vulnerability in the JS engine that runs the Firefox
addons? And in that case, can't an attacker replicates whatever Angular is
doing to make an exploit? Basically it sounds like it's something for Mozilla
to fix, not the Angular team.

~~~
odbol_
Exactly. If you can write a vulnerability in Angular, you can write it in
vanilla Javascript as well. Unless Angular is using `eval()` or something and
Firefox bans any use of `eval()`, which is reasonable...

~~~
bzbarsky
> Unless Angular is using `eval()`

Which it is, as far as I can see, though it tried to make it slightly safer
... until version 1.6, when it gave up on pretending it's at all safe. The
linked slide share from the github issue talks about this a bit. See
[http://www.slideshare.net/x00mario/an-abusive-
relationship-w...](http://www.slideshare.net/x00mario/an-abusive-relationship-
with-angularjs) slides 16-31 which talk about the sandbox angular tried to
apply to the environment it did the eval() in, but in the end it's grabbing
text from the DOM and doing an eval().

Note that in a browser extension doing text from the DOM (controlled by the
web page) and doing an eval (with the privileges of the extension!) is
obviously really really bad.

[Disclaimer: I work for Mozilla and I'm not an expert on Angular.]

------
angry-hacker
Can someone explain me:

If angular can do it, so can just plain javascript? Then it's a problem with
their extension architecture?

As much as I hate bundling big libraries everywhere, why ban angular?

Also, is it possible the researcher wants to get money from Google and didn't
want the vulnerability to be shared?

~~~
AgentME
Yes, you can write vulnerable code in plain javascript:

    
    
        eval(document.querySelector('.foo').textContent);
    

In a regular web page where you don't allow the user to insert arbitrary HTML,
it's a perfectly fine line allowing you to store code in the DOM.

If you do that in a browser extension where the DOM is controlled by the web
page, then you've got a big security vulnerability: the webpage can put
anything it wants into a foo tag and then your extension will execute it with
its privileges! Your extension will be taken down from the Firefox Addons
Marketplace if it's reviewed and this line is found running. If lots of
extensions added this line, then Mozilla would probably automate blocking
extensions from containing it.

Angular 1.x does something like this line. It's perfectly fine in web pages
where you control the DOM, but is insecure if the DOM comes from an untrusted
outsider!

~~~
angry-hacker
Why doesn't Firefox simply disallow eval? You would get an error in console
explaining and that's it.

~~~
kevingadd
Lots of perfectly sensible JavaScript code uses eval for things like feature
detection and runtime code generation. If you removed eval they'd just use
'new Function' instead, which has most of the same problems.

------
yc-kraln
"we were not able to report them to angular as the security researcher who
found them asked us to not share them."

Nice.

~~~
moron4hire
I read that and said a literal WTF. How is it at all acceptable to honor such
a request? What possible good reason could there be?

Unless the discloser was the US Government and the request was actually a
court order. But this seems ludicrous. If they require secrecy around the
exploit, they wouldn't have disclosed it to Mozilla at all.

~~~
Jare
Mozilla is probably unable to disclose not just the vulnerability, but other
surrounding info they may have been provided, including which other parties
have received that info. They are not saying the Angular team is unaware of
the problem, right? Only that they themselves are not the ones reporting it.

If you don't honor such request without a VERY STRONG reason, nobody in their
right mind will ever disclose anything to you ever again. Right now we don't
and can't know if such a strong reason exists.

~~~
moron4hire
"They are not saying the Angular team is unaware of the problem, right?"

Are we just going to assume the folks at Mozilla are clairvoyants? How would
they know what the Angular team knows? If it's known in general that the
Angular team knows about this issue already, perhaps through other means, then
the statement that they haven't disclosed this to the Angular team makes no
sense. The statement is, "Mozilla is choosing to do it's part to keep Angular
in the dark about this."

~~~
TheRealPomax
Well, there's [https://github.com/mozilla/addons-
linter/issues/1000#issueco...](https://github.com/mozilla/addons-
linter/issues/1000#issuecomment-255183470) ...

~~~
Jare
And now one of the researcher has commented
[https://github.com/mozilla/addons-
linter/issues/1000#issueco...](https://github.com/mozilla/addons-
linter/issues/1000#issuecomment-256183820)

------
mschuster91
What is justifying this?

If the vulnerable part is in Angular, there's a 100% chance that someone can
write code in plain JS that is vulnerable to the same attack. E.g. if there
was something in the hashbang-url-router that would lead to eval'ing the code
in the hash (which I just made up, but would describe such a class of
vulnerability). This means it's pointless to ban Angular.

If something Angular does triggers an issue in the Firefox JS engine, it is
Firefox that should be fixed, instead of allowing essentially a 0day exploit
to be alive.

~~~
minitech
> If the vulnerable part is in Angular, there's a 100% chance that someone can
> write code in plain JS that is vulnerable to the same attack.

“can”, not “will”. If _everything_ that uses Angular is vulnerable (unlikely?
I couldn’t say), why would you not ban it? This is along the lines of “If
Heartbleed is in OpenSSL, there’s a 100% chance that someone can write code in
plain C that is vulnerable to the same attack”. Yeah, they can, and it happens
all the time, but why not fix a known hole?

> E.g. if there was something in the hashbang-url-router that would lead to
> eval'ing the code in the hash (which I just made up, but would describe such
> a class of vulnerability). This means it's pointless to ban Angular.

This would be an excellent reason to ban Angular since a huge majority* of
extensions never use eval().

* If this isn’t true… I don’t want to be in web dev anymore.

------
pfooti
Let me make sure I understand this. This vulnerability is basically because
the addon authors are using angular to parse webpages, and therefore because
they don't have control over the DOM elements angular is being used on,
they're vulnerable to all the xss escapes in [0], right?

Because as far as I can tell, all of the escapes in [0] require the attacker
to write to the DOM being evaluated by the angular engine. Normally this isn't
a big deal, because the developer controls the DOM. In more pedestrian
situations, if you've got a wiki, cms, forum, or other situation where
untrusted people are creating content, you can't give those content creators
the ability to write to parts of the DOM where an xss abuse might happen, and
if you do it is pretty much your fault anyway (angular isn't really to blame
here, because if you're letting users write to the DOM directly you've got
trust issues).

The mozilla situation is particularly problematic because the mozilla addon
runs its javascript context in some elvated privilege mode, and normally that
javascript just manipulates the DOM directly to generate addon-specific UI
(like password fill helpers, for example). But because that angular is being
run on a DOM outside of the control of the addon authors, it's also subject to
all kinds of XSS escapes.

I get that, it's fair. Seems like, though, this isn't really an angularjs
issue specifically. It feels like this is a broad problem with the security
model for browser addons. Like: replace angular with some other view library
that you rolled yourself and it could still have all kinds of issues.

Basically anything that uses the DOM to store state (instead of a one-way
state -> dom transformation) is subject to manipulation by malicious DOM
injections, be they from forum posters or creators of pages that will be
visited by plugin users. So, again: I see why angular1 has issues here. But
this is a much bigger security hole, honestly. I don't think the javascript
runtime for plugins should expose anything to the js running on the page, but
that's a lot more complicated, since the plugin runtime is almost always
really interested in spidering the page DOM and altering it by responding to
the state of that DOM.

0:[http://www.slideshare.net/x00mario/an-abusive-
relationship-w...](http://www.slideshare.net/x00mario/an-abusive-relationship-
with-angularjs)

~~~
AgentME
>I don't think the javascript runtime for plugins should expose anything to
the js running on the page, but that's a lot more complicated, since the
plugin runtime is almost always really interested in spidering the page DOM
and altering it by responding to the state of that DOM.

Firefox/Chrome/Safari extensions already run in an "isolated world" so that
they have separate sets of global variables and DOM-wrappers, so that
javascript values never leak directly and modifications to globals don't
affect other worlds. However, they all see and manipulate the same content in
the DOM. I'm unsure if you're proposing anything different from the current
situation.

------
xxkylexx
Angular and Firefox teams are working to resolve the issue. The issue is not
related to sandbox ... see [https://github.com/mozilla/addons-
linter/issues/1000#issueco...](https://github.com/mozilla/addons-
linter/issues/1000#issuecomment-255269186)

------
BHSPitMonkey
If there is some permutation of JavaScript statements (library or otherwise)
that displays a security vulnerability for the user, isn't that the browser's
fault and not the application's? And isn't library detection just a hacky
substitute for an actual fix of said fault?

~~~
AgentME
It's not the browser's fault if an extension has a vulnerability which gives
away the capabilities the extension was given. It would be the browser's fault
if the extension had a vulnerability which somehow managed to give away more
permissions than the extension was given in the first place.

In this specific case, Angular runs eval-like functions on HTML in the DOM.
The DOM can be controlled by the webpage. If Angular is running in a higher-
privilege extension, then the webpage can put code in the DOM and let Angular
execute it from within the extension. This seems to be a fundamental part of
Angular 1.x's design. It just isn't built for this use case.

~~~
BHSPitMonkey
That makes sense, thanks.

------
secmax
I am really worried about the security implications for addons like bitwarden,
if mozilla is right about this. I hope that competent people will take a close
look.

------
jmcdiesel
Isn't any "vulnerability" in a JS framework a vulnerability in the browser's
own handling of securing it? Like, there is nothing angular is doing that
someone else couldn't do, intentionally, to create said issue, right? Wouldn't
the correct handling of this to be to secure the damned interpreter thats
running the code to prevent it from having the effect they are trying to
mitigate?

This feels like a lazy shifting of blame

~~~
AgentME
Angular evals text stored in the DOM. If you alone are in control of the DOM
(like in a normal webpage), there's no issue. If someone else is in control of
the DOM (you're running Angular in a higher-privileged extension running on a
random webpage's DOM), then they can put code into the DOM which then gets
picked up by Angular and executed within the extension with the extension's
full permissions. This isn't an issue inherent to the language or browser at
all. This is an issue just comes from that Angular 1.x is designed for use-
cases where the DOM is trusted, and that's not the case for browser
extensions.

~~~
jmcdiesel
But thats not special to angular... right? You can write that in vanilla
javascript just the same - the issue is that the script running in the
extension is given the ability to do that. They dont seem to be blocking a
feature in javascript, they seem to be blocking a lib that uses it. Angular
can't do ANYTHING that any other bit of javascript can't do in the same
context.

Angular is just JS, its not special JS, its just JS. If angular can do
something, it can be done without angular so blocking angular does nothing to
prevent the vulnerability.

~~~
AgentME
Eval has legitimate uses, and there's plenty of ways that extensions can be
insecure or malicious without using eval.

Firefox's Addons Marketplace reviews extensions and rejects ones that are
malicious or insecure.

The issue is not that Angular uses an inherent insecure feature. The issue is
that Angular does insecure things: it lets a webpage run any code with the
extension's privileges. If the extension has privileges to your email domain,
then the webpage can abuse the extension's privileges to harvest your email.
An extension that let your email be harvested would get rejected regardless of
whether it used eval or not. (For example, a malicious extension could be made
which doesn't use eval and is just a couple hard-coded lines to make
privileged AJAX connections to gmail.com. There's no technical features that
the extension is using that shouldn't be available.)

------
draw_down
If they had let this through and people got owned because of it people would
be screaming at Mozilla. Damned if they do...

------
adrin2
Uhm, wait what? Firefox extensions can execute literal code from visited a
website? To me that sounds like the root cause of the problem and a glaring
security hole - either the website has to be sanitized/projected into a
harmless dom abstraction or extensions shouldn't be able to use any kind of
dynamic evals.

Sure angular may be vulnerable by default but good luck thinking that all
other extensions out there are safe and not using evals at any point.

~~~
AgentME
>either the website has to be sanitized/projected into a harmless dom
abstraction

Should Firefox contain code to recognize text that looks like Angular
templates and then break it somehow? That'd be extremely specific.

Eval isn't an inherently unsafe feature, and it doesn't have a monopoly on
insecurity: Angular doesn't even require eval. It can run without eval in a
CSP-supporting mode that's equally vulnerable.

------
supersan
Angular 1.x is still quite being actively developed and it will be many years
before it will become unsupported. I'm sure if they report the vulnerability
it would be fixed instantly seeing the amount of activity on github.

~~~
AgentME
The issue is a fundamental part of Angular 1.x's design. It runs eval on text
within the page DOM. This isn't secure within extensions where the page DOM is
controlled by the webpage, and Angular is running within a higher-privileged
extension.

~~~
supersan
> Angular is running within a higher-privileged extension.

Ok, thanks for the explanation. I've developed chrome extensions before but
firefox very long time back, so my knowledge is rusty, but please tell me 2
things:

1\. Say hypothetically if AngularJs can do it, doesn't that mean any
Javascript can do it too? I mean Javasript contained within the extension
code?

2\. In chrome extensions we use "ng-csp", otherwise it won't run. Is this
addressing the same thing in chrome and if so, why can't it do it in firefox?

~~~
AgentME
>1\. Say hypothetically if AngularJs can do it, doesn't that mean any
Javascript can do it too? I mean Javasript contained within the extension
code?

Angular doesn't have a monopoly on insecure code! Anyone can write insecure or
malicious code. Firefox's Addons Marketplace will reject an insecure extension
just the same when they notice anything amiss whether it uses Angular or not.

>2\. In chrome extensions we use "ng-csp", otherwise it won't run. Is this
addressing the same thing in chrome and if so, why can't it do it in firefox?

Chrome enforces a CSP directive that prohibits eval in UI pages. This is
unrelated to Angular being insecure to use in extension content scripts. (When
I've said a few times that Angular is insecure because it "evals content from
the DOM", I'm not trying to be specific to the `eval` function. I think its
CSP fallback is just as insecure.) Angular 1.x is bad news in Chrome content
scripts just the same.

------
esafwan
That suddenly makes Angular look scary for some clients. vulnerability that is
known to an entity/entities but unknown to the Angular developers or
contributors....

~~~
codedokode
The vulnerability occurs only if you inject Angular into a web page from
browser extension in some browsers. There is no vulnerability if you are
writing a SPA using Angular.

------
cfvergara
Why not use Google Caja instead of a separate sandbox?

~~~
minitech
Overkill for what was never intended to be a sandbox for untrusted code. The
“sandboxing”, like Django templates’, Jinja, Nunjucks, etc. is a well-intended
measure to keep logic out of templates, but in practice only really gets in
the way and causes mistaken assumptions about security.

------
nathancahill
Title should by "Angular 1.x Banned from Firefox Addons"

~~~
sctb
Thank you, we've updated the title from “Angular 1.x Ban”.

------
andrewvijay
Thats some solid hate right there. Not expected from Mozilla at all!

------
viach
Nice extension marketing

------
buremba
This thing makes me believe that we should not use any OSS project which
released by a big companies such as Google and Microsoft. Even if they don't
say that they're dropping support, when they start to work on another project,
it won't be a community-driven project and slowly die.

