Live data from Hacker News

Angular 1.x Banned from Firefox Addons

github.com

151–160 of 222 posts

Re: Angular 1.x Banned from Firefox Addons

#151

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.

What's the rationale for disclosing vulnerabilities to for example Google before going public (unless the bug is in Google's software)?

Re: Angular 1.x Banned from Firefox Addons

#152
post #62

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.

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

Firefox Addons Marketplace reviews and bans malicious and insecure extensions. There are legitimate uses of eval. Angular's use of eval (on DOM content) is insecure within the context of browser extensions.

Re: Angular 1.x Banned from Firefox Addons

#153
post #6

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?

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.

Re: Angular 1.x Banned from Firefox Addons

#154

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?

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

#155

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

[deleted]

Re: Angular 1.x Banned from Firefox Addons

#156

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?

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…

I had an extension a while ago that I was attempting to publish to the Firefox app store and it was rejected on grounds of using eval. I don't remember why I needed to use eval, but basically this is something they do already. I'm guessing that previously they were allowing for an Angular exception.

Re: Angular 1.x Banned from Firefox Addons

#157
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.

Re: Angular 1.x Banned from Firefox Addons

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

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

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

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

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

0:http://www.slideshare.net/x00mario/an-abusive-relationship-w...

Re: Angular 1.x Banned from Firefox Addons

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

Re: Angular 1.x Banned from Firefox Addons

#160

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

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