13 ms·

Angular 1.x Banned from Firefox Addons

384 points by secmax 10y ago

viach 10y ago
Nice extension marketing
smrtinsert 10y ago
> 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 10y ago
  Yeah that doesn't sound true at all.
  - mlent 10y ago
    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 10y ago
      At least until they get tired and change their minds, which may not take that long.
      - wnevets 10y ago
        while could be true, its probably not currently the case.
      - coding123 10y ago
        Even if that did, there might be a community that pops up to take on the burden instead of G.
- vonklaus 10y ago
  based on that statement and others my read is basically: We know a lot of important people and they gave us information you don't have, to which we have made business decisions that affect you that we didn't communicate. Did we tell you? no. Now that you know, are we going to elaborate? nope. trust us, our people on the inside will be proven correct soon enough, so you can thank us later.
- Narretz 10y ago
  This is not correct. Development of 1.x is still very much under Google's control.
secmax 10y ago
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.
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.
encoderer 10y ago
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.
- capote 10y ago
  It is strange. On the other hand there's something suspicious here. Some things clearly aren't being communicated properly.
  - FireBeyond 10y ago
    Yeah, definitely odd. "We banned any package containing Angular 1.x. We received a security report. One that we were asked not to share with you, one that we didn't even mention, we just went ahead and implemented the ban, didn't tell anybody."
- xxkylexx 10y ago
  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 10y ago
    I think encoderer was referring to https://github.com/mozilla/addons-linter/issues/1000#issuecomment-255096658 https://github.com/mozilla/addons-linter/issues/1000#issueco..., where the engineer asks, "Is there any possible way for us to get around this ban?"
    - xxkylexx 10y ago
      Which is referring to the possibility that the application may not be using some feature that is affected by this supposed top secret vulnerability.
nathancahill 10y ago
Title should by "Angular 1.x Banned from Firefox Addons"
- sctb 10y ago
  Thank you, we've updated the title from “Angular 1.x Ban”.
water42 10y ago
For all we know Mozilla is complicit in the black market sale of this vuln by the mystery security researcher. Given Angular 1's popularity, Mozilla has a moral obligation to responsibly disclose this bug to the Angular team and let them determine if its unsolvable or not. Hinting at its existence is one of the worst things they could have done since it will simply give other blackhats motivation to find this vuln while Angular team is not aware of it.
- deleted 10y ago
  [deleted]
- vosper 10y ago
  > For all we know Mozilla is complicit in the black market sale of this vuln by the mystery security researcher. That's a ridiculous claim
  - deleted 10y ago
    [deleted]
  - nchelluri 10y ago
    I can't help but think that he's right though. Not explicitly but implicitly. By keeping the vulnerability from the dev team they're allowing it to stay out in the wild. No? Edit: It may be that this is only an issue inside of Firefox extensions (addons). In which case, maybe the point is moot. See: https://github.com/mozilla/addons-linter/blob/master/docs/third-party-libraries.md#angularjs-1x https://github.com/mozilla/addons-linter/blob/master/docs/th...
    - vosper 10y ago
      There's a world of difference between an exploit being known to someone and that exploit being put up for sale on the black market. In either case, if the researcher who found the exploit sold it, that hardly makes Mozilla complicit in his actions.
      - 10y ago
yc-kraln 10y ago
"we were not able to report them to angular as the security researcher who found them asked us to not share them." Nice.
- moron4hire 10y ago
  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 10y ago
    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 10y ago
      "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 10y ago
        Well, there's https://github.com/mozilla/addons-linter/issues/1000#issuecomment-255183470 https://github.com/mozilla/addons-linter/issues/1000#issueco... ...
BHSPitMonkey 10y ago
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 10y ago
  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 10y ago
    That makes sense, thanks.
- Jare 10y ago
  The extension has access to certain information provided by the user and the browser. Due to a vulnerability, that information is no longer secure, and may be used in ways that the user of the extension does not expect nor has approved. The platform holder treats vulnerable extensions as if they were effectively malware, and bans them. Hard to go deeper without further information, but it makes sense to me.
ggregoire 10y ago
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-sandbox-removal.html https://angularjs.blogspot.mx/2016/09/angular-16-expression-...
- deleted 10y ago
  [deleted]
- wnevets 10y ago
  removing the sandbox just removes the illusion of being protected.
  - vladimir-y 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
supersan 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      >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.
laurent123456 10y ago
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.
- AgentME 10y ago
  Angular runs eval-like functions on HTML in the DOM. The DOM can be controlled by the webpage. When Angular runs in an extension (which has more permissions than the page) using the DOM controlled by the webpage, then the webpage can write code into the DOM that Angular executes from within the extension's security context. It's not the browser's fault that Angular trusts the webpage's DOM like that; Angular just isn't built for extensions.
  - jonny_eh 10y ago
    But Angular only reads HTML that it's told to read, specified by the "ng-app" attribute/directive.
    - AgentME 10y ago
      And the webpage can place the ng-app directive into itself.
    - bzbarsky 10y ago
      Yes, but in a browser extension context the web page controls the HTML involved and is the thing you want to defend against. So relying on the HTML to play nice is not OK. [Disclaimer: I work for Mozilla.]
- odbol_ 10y ago
  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...
mschuster91 10y ago
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 10y ago
  > 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.
- willvarfar 10y ago
  As AgentME clarifies above, Angular uses a lot of `eval()` of DOM elements, which is perfectly reasonable design decision when you control the contents (as you would if you used Angular in your own app), but a perfectly awful thing to do if the attacker controls the contents (as they would if you used Angular in a browser extension that processes 3rd party webpages).
- jMyles 10y ago
  > there's a 100% chance that someone can write code in plain JS that is vulnerable to the same attack This is plainly false - please don't spread fear where it doesn't belong. I'm sure you can think of some things that, when written into the privileged environment of an addon, create vulnerabilities that aren't possible in "plain JS." There is nowhere near a "100% chance" that this is a problem for web apps that don't run as browser extensions.
andrewvijay 10y ago
Thats some solid hate right there. Not expected from Mozilla at all!
- deleted 10y ago
  [deleted]
DannyBee 10y ago
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/86f4dfb44355a7de68d87cf72aa678086894dac7 https://github.com/mozilla/addons-linter/commit/86f4dfb44355... 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/2dcc2226e2ec9dea65708b0a1cc97a9cd593d82d https://github.com/mozilla/addons-linter/commit/2dcc2226e2ec...) 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 10y ago
  > 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 10y ago
    I wonder if any business-critical apps stopped working because of this?
- tptacek 10y ago
  Google has repeatedly been equally abrupt in making breaking changes to other people's apps/products/pages/sites to resolve security problems. I'm glad they do, and I'm glad Mozilla isn't fucking around with stuff like this either.
gima 10y ago
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 10y ago
  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 10y ago
    I think his point is that running the entire Angular 1.x framework to power a browser extension gives a large attack surface.
    - nchelluri 10y ago
      Thanks for the clarification.
    - gima 10y ago
      Yes. And to answer nchelluri's question: Auto-typing, though I believe that's available only on desktop operating systems.
      - nixos 10y ago
        > 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
  - andrewstuart2 10y ago
    GNU password manager for me, which interacts with the clipboard (or lets you do so on your own if you prefer). The same is true of Keepass for windows, although IIRC you can also let Keepass actually alt-tab to the last window and do the typing for you.
draw_down 10y ago
If they had let this through and people got owned because of it people would be screaming at Mozilla. Damned if they do...
TheRealPomax 10y ago
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.
esafwan 10y ago
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 10y ago
  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.
Animats 10y ago
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 10y ago
  Agreed and this is why React has been given a pass I think, because it's only for display purposes.
  - vmasto 10y ago
    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.
  - spicyj 10y ago
    React is actively maintained and doesn't have any known security vulnerabilities.
hannob 10y ago
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 10y ago
  That was a good talk. I highly recommend watching the entire video.
cfvergara 10y ago
Why not use Google Caja instead of a separate sandbox?
- minitech 10y ago
  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.
angry-hacker 10y ago
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?
- positr0n 10y ago
  I have no information one way or the other, but maybe the issue isn't that angular can do it, but that angular does do it. So any extension using angular is vulnerable by default.
- AgentME 10y ago
  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 10y ago
    Why doesn't Firefox simply disallow eval? You would get an error in console explaining and that's it.
    - deleted 10y ago
      [deleted]
    - kevingadd 10y ago
buremba 10y ago
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.
jmcdiesel 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.)
adrin2 10y ago
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 10y ago
  >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.
pfooti 10y ago
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-with-angularjs http://www.slideshare.net/x00mario/an-abusive-relationship-w...
- AgentME 10y ago
  >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.
dancek 10y ago
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).
- jguegant 10y ago
  BROWSERS are really dangerous; if you need to keep your machine secure, you shouldn't use any IMHO. By definition, browsers need to be able to access things such as page content. What would stop someone from writing a browser that captures your bank credentials? Nothing. Obviously no security-conscious user is going to install a bank credential stealing browser. But what about bugs in browsers? If a buggy browser can be made to execute arbitrary code, it is as dangerous as a malicious browser... At the end, it's a matter of trust in your browser or your extensions.
  - 10y ago
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
xxkylexx 10y ago
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#issuecomment-255269186 https://github.com/mozilla/addons-linter/issues/1000#issueco...

384 points by secmax 10y ago

viach 10y ago

Nice extension marketing

> 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 10y ago
Yeah that doesn't sound true at all.
- mlent 10y ago
  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 10y ago
    At least until they get tired and change their minds, which may not take that long.
    - wnevets 10y ago
      while could be true, its probably not currently the case.
    - coding123 10y ago
      Even if that did, there might be a community that pops up to take on the burden instead of G.
vonklaus 10y ago
based on that statement and others my read is basically: We know a lot of important people and they gave us information you don't have, to which we have made business decisions that affect you that we didn't communicate. Did we tell you? no. Now that you know, are we going to elaborate? nope. trust us, our people on the inside will be proven correct soon enough, so you can thank us later.
Narretz 10y ago
This is not correct. Development of 1.x is still very much under Google's control.

secmax 10y ago

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.

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.

encoderer 10y ago

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.

capote 10y ago
It is strange. On the other hand there's something suspicious here. Some things clearly aren't being communicated properly.
- FireBeyond 10y ago
  Yeah, definitely odd. "We banned any package containing Angular 1.x. We received a security report. One that we were asked not to share with you, one that we didn't even mention, we just went ahead and implemented the ban, didn't tell anybody."
xxkylexx 10y ago
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 10y ago
  I think encoderer was referring to https://github.com/mozilla/addons-linter/issues/1000#issuecomment-255096658 https://github.com/mozilla/addons-linter/issues/1000#issueco..., where the engineer asks, "Is there any possible way for us to get around this ban?"
  - xxkylexx 10y ago
    Which is referring to the possibility that the application may not be using some feature that is affected by this supposed top secret vulnerability.

nathancahill 10y ago

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

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

water42 10y ago

For all we know Mozilla is complicit in the black market sale of this vuln by the mystery security researcher. Given Angular 1's popularity, Mozilla has a moral obligation to responsibly disclose this bug to the Angular team and let them determine if its unsolvable or not. Hinting at its existence is one of the worst things they could have done since it will simply give other blackhats motivation to find this vuln while Angular team is not aware of it.

deleted 10y ago
[deleted]
vosper 10y ago
> For all we know Mozilla is complicit in the black market sale of this vuln by the mystery security researcher. That's a ridiculous claim
- deleted 10y ago
  [deleted]
- nchelluri 10y ago
  I can't help but think that he's right though. Not explicitly but implicitly. By keeping the vulnerability from the dev team they're allowing it to stay out in the wild. No? Edit: It may be that this is only an issue inside of Firefox extensions (addons). In which case, maybe the point is moot. See: https://github.com/mozilla/addons-linter/blob/master/docs/third-party-libraries.md#angularjs-1x https://github.com/mozilla/addons-linter/blob/master/docs/th...
  - vosper 10y ago
    There's a world of difference between an exploit being known to someone and that exploit being put up for sale on the black market. In either case, if the researcher who found the exploit sold it, that hardly makes Mozilla complicit in his actions.
    - 10y ago

yc-kraln 10y ago

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

moron4hire 10y ago
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 10y ago
  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 10y ago
    "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 10y ago
      Well, there's https://github.com/mozilla/addons-linter/issues/1000#issuecomment-255183470 https://github.com/mozilla/addons-linter/issues/1000#issueco... ...

BHSPitMonkey 10y ago

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 10y ago
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 10y ago
  That makes sense, thanks.
Jare 10y ago
The extension has access to certain information provided by the user and the browser. Due to a vulnerability, that information is no longer secure, and may be used in ways that the user of the extension does not expect nor has approved. The platform holder treats vulnerable extensions as if they were effectively malware, and bans them. Hard to go deeper without further information, but it makes sense to me.

ggregoire 10y ago

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-sandbox-removal.html https://angularjs.blogspot.mx/2016/09/angular-16-expression-...

deleted 10y ago
[deleted]
wnevets 10y ago
removing the sandbox just removes the illusion of being protected.
- vladimir-y 10y ago
  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 10y ago
    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 10y ago
      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 10y ago

supersan 10y ago

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

laurent123456 10y ago

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.

AgentME 10y ago
Angular runs eval-like functions on HTML in the DOM. The DOM can be controlled by the webpage. When Angular runs in an extension (which has more permissions than the page) using the DOM controlled by the webpage, then the webpage can write code into the DOM that Angular executes from within the extension's security context. It's not the browser's fault that Angular trusts the webpage's DOM like that; Angular just isn't built for extensions.
- jonny_eh 10y ago
  But Angular only reads HTML that it's told to read, specified by the "ng-app" attribute/directive.
  - AgentME 10y ago
    And the webpage can place the ng-app directive into itself.
  - bzbarsky 10y ago
    Yes, but in a browser extension context the web page controls the HTML involved and is the thing you want to defend against. So relying on the HTML to play nice is not OK. [Disclaimer: I work for Mozilla.]
odbol_ 10y ago
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...

mschuster91 10y ago

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 10y ago
> 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.
willvarfar 10y ago
As AgentME clarifies above, Angular uses a lot of `eval()` of DOM elements, which is perfectly reasonable design decision when you control the contents (as you would if you used Angular in your own app), but a perfectly awful thing to do if the attacker controls the contents (as they would if you used Angular in a browser extension that processes 3rd party webpages).
jMyles 10y ago
> there's a 100% chance that someone can write code in plain JS that is vulnerable to the same attack This is plainly false - please don't spread fear where it doesn't belong. I'm sure you can think of some things that, when written into the privileged environment of an addon, create vulnerabilities that aren't possible in "plain JS." There is nowhere near a "100% chance" that this is a problem for web apps that don't run as browser extensions.

andrewvijay 10y ago

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

deleted 10y ago
[deleted]

DannyBee 10y ago

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/86f4dfb44355a7de68d87cf72aa678086894dac7 https://github.com/mozilla/addons-linter/commit/86f4dfb44355... 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/2dcc2226e2ec9dea65708b0a1cc97a9cd593d82d https://github.com/mozilla/addons-linter/commit/2dcc2226e2ec...) 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 10y ago
> 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 10y ago
  I wonder if any business-critical apps stopped working because of this?
tptacek 10y ago
Google has repeatedly been equally abrupt in making breaking changes to other people's apps/products/pages/sites to resolve security problems. I'm glad they do, and I'm glad Mozilla isn't fucking around with stuff like this either.

gima 10y ago

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 10y ago
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 10y ago
  I think his point is that running the entire Angular 1.x framework to power a browser extension gives a large attack surface.
  - nchelluri 10y ago
    Thanks for the clarification.
  - gima 10y ago
    Yes. And to answer nchelluri's question: Auto-typing, though I believe that's available only on desktop operating systems.
    - nixos 10y ago
      > 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
- andrewstuart2 10y ago
  GNU password manager for me, which interacts with the clipboard (or lets you do so on your own if you prefer). The same is true of Keepass for windows, although IIRC you can also let Keepass actually alt-tab to the last window and do the typing for you.

draw_down 10y ago

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

TheRealPomax 10y ago

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.

esafwan 10y ago

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

Animats 10y ago

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 10y ago
Agreed and this is why React has been given a pass I think, because it's only for display purposes.
- vmasto 10y ago
  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.
- spicyj 10y ago
  React is actively maintained and doesn't have any known security vulnerabilities.

hannob 10y ago

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 10y ago
That was a good talk. I highly recommend watching the entire video.

cfvergara 10y ago

Why not use Google Caja instead of a separate sandbox?

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

angry-hacker 10y ago

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?

positr0n 10y ago
I have no information one way or the other, but maybe the issue isn't that angular can do it, but that angular does do it. So any extension using angular is vulnerable by default.
AgentME 10y ago
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 10y ago
  Why doesn't Firefox simply disallow eval? You would get an error in console explaining and that's it.
  - deleted 10y ago
    [deleted]
  - kevingadd 10y ago

buremba 10y ago

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.

jmcdiesel 10y ago

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

adrin2 10y ago

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

pfooti 10y ago

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-with-angularjs http://www.slideshare.net/x00mario/an-abusive-relationship-w...

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

dancek 10y ago

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).

jguegant 10y ago
BROWSERS are really dangerous; if you need to keep your machine secure, you shouldn't use any IMHO. By definition, browsers need to be able to access things such as page content. What would stop someone from writing a browser that captures your bank credentials? Nothing. Obviously no security-conscious user is going to install a bank credential stealing browser. But what about bugs in browsers? If a buggy browser can be made to execute arbitrary code, it is as dangerous as a malicious browser... At the end, it's a matter of trust in your browser or your extensions.
- 10y ago

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

xxkylexx 10y ago

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#issuecomment-255269186 https://github.com/mozilla/addons-linter/issues/1000#issueco...