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).
> 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.
> 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.
Completely agreed. This is why it's so frustrating that all of the browser vendors have moved to this, "gut every minor option/feature possible, people can just get an extension" attitude.
For Firefox:
* removing the option to not maintain download history
* removing the option for the compact drop-down menu from the URL bar
* forcing tabs on top
* forcing refresh button to the right-hand side of the interface
For Chrome:
* removing backspace navigation (you may dislike it, but others don't)
* disabling middle-click to scroll on Linux
* removing the option to set your new tab page (eg to about:blank)
* not letting you prevent HTML5 video autoplay
* not letting you disable WebRTC
Just the backspace extension alone requires basically carte blanche access to everything just to be able to insert a tiny Javascript function to catch the keypress.
I'm not asking for us to go back to the Mozilla suite with integrated mail client, news reader, etc. Just ... it's okay to have an "advanced options" section that lets us control some of this really simple, really basic stuff. And not only okay, a major security benefit to do so. All the focus on web security, you'd think they'd take this stuff more seriously.
> 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.
Sandboxing in JS should be possible these days. Spin up an iframe, add the sandboxing attribute, load javascript into it, postMessage the code you want to execute to it, await the return value. voila, you executed untrusted code in an isolated origin context.
But the issue of preventing arbitrary Javascript code from running based on user input isn't limited to Angular, it's a problem since the beginning of time!
What about Angular is so special that it needs to be blacklisted? It will likely still be safer than ad-hoc client-side templating that people will do instead.
> By definition, browser extensions need to be able to access things such as page content.
On Firefox/XUL maybe. Web Extensions (like in Chrome) work much like Android apps: You need to acknowledge their desired permissions up front. They can’t request more later.
Of course you may need these permissions to create your extension.
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.
Note that the Angular team is working with Mozilla and the researcher on this (see 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.
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.
The mentioned vulnerability was most likely another sandbox escape. The sandbox is described as "not a defense mechanism" by the Angular team, and the sandbox was removed entirely in the 1.6 release[0]. They admit that Angular isn't secure for cases where an attacker can control the template: this case includes extensions! I'm not going to fault someone for not reporting a security issue with an already-removed feature specifically described as not a security feature.
Before anyone misreads this: the sandbox being removed in 1.6 doesn't mean that Angular 1.6 is safe to use in extensions. It just means that Angular stopped pretending it was safe there. A fundamental part of Angular is evaling text from the DOM. If the DOM is controlled by an attacker, such as a webpage trying to elevate to extension privileges, then you're out of luck. Sandboxing eval is a very large and difficult task that would bloat Angular, all for a use-case that they are not interested in. Angular 1.x is the wrong tool for the job.
NDAs are a real, if insane, thing still to this day
Some of the big security bugs recently have been disclosed to big players like Google and AWS before they were publicly disclosed.
If you want to retain that privilege, you need to show you can keep your mouth shut when security researchers disclose something to you - NDA or otherwise.
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.
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.
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.
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.
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.
The vulnerability specifically has to do with Angular being used in extensions where the extension has more privileges than the webpage it's affecting. Judging by http://www.slideshare.net/x00mario/an-abusive-relationship-w..., the issue has to do with a general design feature of Angular: it runs eval-like functions on text within the page DOM. Angular simply isn't built for the page DOM is controlled by an attacker (ie. Angular is running in a higher-privilege extension, and the webpage controls the DOM and wants to inject code into the higher-privilege extension). Angular has band-aids over a few specific ways that this can be taken advantage of, but it's extremely difficult to make bullet-proof (as blacklisting strategies often are) and it's not an issue that affects regular non-extension web pages.
The explanation is in the issue thread now. If you have Angular running in an extension, if it sees Angular tags in the page you're viewing, it could execute them with the elevated permissions of the extension instead of the permissions of the page.
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?
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.
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.
The issue with Angular in extensions has to do with the fact it uses eval on the page DOM, which is controlled by the webpage. The webpage can put code into the DOM, and then let Angular execute it from within the higher-privileged extension.
Angular <1.6 had a sandbox feature which blacklisted specific attacks like this, but was not a general solution and was specifically not intended as a security feature. They entirely removed the sandbox in 1.6 because people kept thinking it was a security feature: http://angularjs.blogspot.com/2016/09/angular-16-expression-...
I'm not going to fault someone for not reporting a specific vulnerability with a specifically not-security feature that has already been removed.
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.)
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.
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
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.
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.
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.
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...
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.
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.
> 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.
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).
> 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.
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.
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?
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.
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?
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.
[+] [-] dancek|9 years ago|reply
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|9 years ago|reply
> 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.
[+] [-] byuu|9 years ago|reply
Completely agreed. This is why it's so frustrating that all of the browser vendors have moved to this, "gut every minor option/feature possible, people can just get an extension" attitude.
For Firefox:
* removing the option to not maintain download history
* removing the option for the compact drop-down menu from the URL bar
* forcing tabs on top
* forcing refresh button to the right-hand side of the interface
For Chrome:
* removing backspace navigation (you may dislike it, but others don't)
* disabling middle-click to scroll on Linux
* removing the option to set your new tab page (eg to about:blank)
* not letting you prevent HTML5 video autoplay
* not letting you disable WebRTC
Just the backspace extension alone requires basically carte blanche access to everything just to be able to insert a tiny Javascript function to catch the keypress.
I'm not asking for us to go back to the Mozilla suite with integrated mail client, news reader, etc. Just ... it's okay to have an "advanced options" section that lets us control some of this really simple, really basic stuff. And not only okay, a major security benefit to do so. All the focus on web security, you'd think they'd take this stuff more seriously.
[+] [-] the8472|9 years ago|reply
Sandboxing in JS should be possible these days. Spin up an iframe, add the sandboxing attribute, load javascript into it, postMessage the code you want to execute to it, await the return value. voila, you executed untrusted code in an isolated origin context.
[+] [-] rtpg|9 years ago|reply
What about Angular is so special that it needs to be blacklisted? It will likely still be safer than ad-hoc client-side templating that people will do instead.
[+] [-] fuzzy2|9 years ago|reply
On Firefox/XUL maybe. Web Extensions (like in Chrome) work much like Android apps: You need to acknowledge their desired permissions up front. They can’t request more later.
Of course you may need these permissions to create your extension.
[+] [-] revelation|9 years ago|reply
You make it sound automatic, but surely this must be manually triggered by the extension in question?
[+] [-] jguegant|9 years ago|reply
At the end, it's a matter of trust in your browser or your extensions.
[+] [-] TheRealPomax|9 years ago|reply
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|9 years ago|reply
Let's be good GH citizens. :-) Nobody benefits from the Issue ending up locked because the discussion got too off-topic.
[+] [-] AgentME|9 years ago|reply
Before anyone misreads this: the sandbox being removed in 1.6 doesn't mean that Angular 1.6 is safe to use in extensions. It just means that Angular stopped pretending it was safe there. A fundamental part of Angular is evaling text from the DOM. If the DOM is controlled by an attacker, such as a webpage trying to elevate to extension privileges, then you're out of luck. Sandboxing eval is a very large and difficult task that would bloat Angular, all for a use-case that they are not interested in. Angular 1.x is the wrong tool for the job.
[0] http://angularjs.blogspot.com/2016/09/angular-16-expression-...
[+] [-] michaelt|9 years ago|reply
If you want to retain that privilege, you need to show you can keep your mouth shut when security researchers disclose something to you - NDA or otherwise.
[+] [-] secmax|9 years ago|reply
I agree! There are a lot of Chrome extensions out there which could be affected. Immediate public disclose would be irresponsible.
[+] [-] DannyBee|9 years ago|reply
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...
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...) 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.
[+] [-] Animats|9 years ago|reply
[+] [-] omouse|9 years ago|reply
[+] [-] phs2501|9 years ago|reply
What is going on here?
[+] [-] nathancahill|9 years ago|reply
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.
[+] [-] AgentME|9 years ago|reply
[+] [-] vladimir-y|9 years ago|reply
[+] [-] TD-Linux|9 years ago|reply
[+] [-] tiglionabbit|9 years ago|reply
[+] [-] encoderer|9 years ago|reply
That's an interesting approach.
[+] [-] xxkylexx|9 years ago|reply
[+] [-] capote|9 years ago|reply
[+] [-] ggregoire|9 years ago|reply
Angular 1.6 - Expression Sandbox Removal: https://angularjs.blogspot.mx/2016/09/angular-16-expression-...
[+] [-] gima|9 years ago|reply
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.
[+] [-] AgentME|9 years ago|reply
Angular <1.6 had a sandbox feature which blacklisted specific attacks like this, but was not a general solution and was specifically not intended as a security feature. They entirely removed the sandbox in 1.6 because people kept thinking it was a security feature: http://angularjs.blogspot.com/2016/09/angular-16-expression-...
I'm not going to fault someone for not reporting a specific vulnerability with a specifically not-security feature that has already been removed.
[+] [-] nchelluri|9 years ago|reply
[+] [-] smrtinsert|9 years ago|reply
I totally missed this - was there a notice of this posted somewhere?
[+] [-] wnevets|9 years ago|reply
[+] [-] vonklaus|9 years ago|reply
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.
[+] [-] hannob|9 years ago|reply
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.
[+] [-] laurent123456|9 years ago|reply
[+] [-] AgentME|9 years ago|reply
[+] [-] odbol_|9 years ago|reply
[+] [-] angry-hacker|9 years ago|reply
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?
[+] [-] yc-kraln|9 years ago|reply
Nice.
[+] [-] moron4hire|9 years ago|reply
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.
[+] [-] mschuster91|9 years ago|reply
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|9 years ago|reply
“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|9 years ago|reply
[+] [-] jMyles|9 years ago|reply
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.
[+] [-] pfooti|9 years ago|reply
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...
[+] [-] xxkylexx|9 years ago|reply
[+] [-] BHSPitMonkey|9 years ago|reply
[+] [-] secmax|9 years ago|reply
[+] [-] jmcdiesel|9 years ago|reply
This feels like a lazy shifting of blame
[+] [-] AgentME|9 years ago|reply
[+] [-] draw_down|9 years ago|reply