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? Pr…
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.
Angular 1.x Banned from Firefox Addons
151–160 of 222 posts
Re: Angular 1.x Banned from Firefox Addons
#152That 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.
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...
Re: Angular 1.x Banned from Firefox Addons
#153So 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?
Re: Angular 1.x Banned from Firefox Addons
#154Can 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?
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 in…
Re: Angular 1.x Banned from Firefox Addons
#155Earlier quoted context omitted.
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 in…
Why doesn't Firefox simply disallow eval? You would get an error in console explaining and that's it.
Re: Angular 1.x Banned from Firefox Addons
#156Can 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?
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 in…
Re: Angular 1.x Banned from Firefox Addons
#157Sure 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.
Re: Angular 1.x Banned from Firefox Addons
#158Because 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...
Re: Angular 1.x Banned from Firefox Addons
#159Browser 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).
Re: Angular 1.x Banned from Firefox Addons
#160Earlier quoted context omitted.
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 in…
Why doesn't Firefox simply disallow eval? You would get an error in console explaining and that's it.