Angular 1.x Banned from Firefox Addons • Hacker News Board

Re: Angular 1.x Banned from Firefox Addons

#171

Post by [deleted] » Thu, Oct 20, 2016, 9:51 PM UTC

AgentME wrote: post #132

masklinn wrote: post #117

Earlier quoted context omitted.

Chrome extensions are less of an issue though, no? IIRC Firefox addons are significantly more powerful than Chrome extensions, so locking things down tighter makes sense anyway, a low threat on Chrome could be much higher on FF.

If a Chrome extension has permissions to an origin, then it can freely make cross-domain requests to it from any page. So if you have an extension using Angular 1.x on every page and then browse to a malicious page, then the page could contain text in the DOM that Angular evals from within the extension. That code could then make an AJAX request to any origin with your cookies, and make requests for your bank info or…

[deleted]

Re: Angular 1.x Banned from Firefox Addons

#172

Post by the8472 » Thu, Oct 20, 2016, 10:00 PM UTC

dancek wrote: post #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 in…

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

Re: Angular 1.x Banned from Firefox Addons

#173

Post by NeutronBoy » Thu, Oct 20, 2016, 10:05 PM UTC

barkbro wrote: post #151

michaelt wrote: post #119

Earlier quoted context omitted.

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

Because big players can take remedial action prior to the bug being disclosed to protect users - for example, banning a specific framework from browser extensions.

Re: Angular 1.x Banned from Firefox Addons

#174

Post by NeutronBoy » Thu, Oct 20, 2016, 10:07 PM UTC

nchelluri wrote: post #67

gima wrote: post #63

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.

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

I use Keepass with auto-type. I know it's not perfect, but I feel better about auto-type than browser extensions.

Re: Angular 1.x Banned from Firefox Addons

#175

Post by sctb » Thu, Oct 20, 2016, 10:12 PM UTC

water42 wrote: post #15

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 wh…

We detached this subthread from https://news.ycombinator.com/item?id=12754354 and marked it off-topic.

Re: Angular 1.x Banned from Firefox Addons

#176

Post by AgentME » Thu, Oct 20, 2016, 10:20 PM UTC

the8472 wrote: post #172

dancek wrote: post #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 in…

> 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, loa…

You can't run code that depends on variables in the page context though. If all the input values are serializable, then you can postMessage them into the iframe too, but you can't serialize objects with arbitrary methods, etc. The code you run in the sandbox can't return back a rich object with arbitrary methods because that has to get serialized back out. You can't use getters and setters to transparently proxy all accesses because postMessage is asynchronous. Even if you restrict everything to only dealing with objects with promise-returning functions, I'm not entirely sure if you can get this all to play nicely with garbage collection (say you have an object outside of the iframe which is only referenced -- through the proxy system -- by an object inside the iframe which is only referenced by that object outside of the iframe)...

Iframe-sandboxing is far from a drop-in solution to this type of problem into an existing codebase.

Re: Angular 1.x Banned from Firefox Addons

#177

Post by michaelt » Thu, Oct 20, 2016, 10:28 PM UTC

barkbro wrote: post #151

michaelt wrote: post #119

Earlier quoted context omitted.

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

When you release a patch, anyone who gets it can see what you changed and figure out an exploit from that. Because it's good for people to be patched /before/ that happens, some vendors give certain major customers early access to patches - so long as they maintain a proven track record of not disclosing anything about them.

For example, Xen has a 'pre-disclosure list' [1] so if they have a critical security patch, Amazon, Google, Linode, Oracle, Rackspace, and several Linux distro developers [2] get the patches early.

Obviously, we can debate the morality and wisdom of this policy - personally as I haven't discovered any critical security bugs, I've never faced this particular moral conundrum.

[1] https://www.xenproject.org/security-policy.html [2] http://www.securityweek.com/several-flaws-patched-xen-hyperv...

Re: Angular 1.x Banned from Firefox Addons

#178

Post by mi_g » Thu, Oct 20, 2016, 10:35 PM UTC

bzbarsky wrote: post #106

codedokode wrote: post #100

Earlier quoted context omitted.

Don't extensions have their own DOM (like they have in Chrome)? Why would anyone run Angular on a browser page? It would probably conflict with existing application. It looks like Firefox extension architecture has design problems. And I don't like the presentation. One could think that Angular is vulnerable which is not true. The vulnerability appears when it is used in a wrong way in a browser extension.

> Don't extensions have their own DOM They can. They can also manipulate the page DOM. > Why would anyone run Angular on a browser page? Because you want to manipulate its DOM and Angular is what you're familiar with? > It would probably conflict with existing application Note that it would operate on the same _DOM_ but not in the same scripting environment. That is, if you have a DOM element "foo" that comes from th…

Thanks Boris, this makes more sense.

So the risk is that an add-on would inject angular 1.x into an external web site, this web site being malicious, it modifies its own DOM, so that angular would eval expressions from this DOM within the scripting environment running at a higher privilege.

What if the malicious web site does something like ? On Firefox, i verified this loads angular into the web site, but what about the privilege level ? Will it be the original one from the page or higher ?

As a side note, doing the Chrome equivalent , the loading fails with an exception saying "chrome-extension://" is not an allowed source.

In my extension, i modified the angular.min.js file to insert this as the first line:

(typeof window!=="undefined" && window.location && window.location.href && window.location.href.startsWith("resource://my-extension/")) || (function() { throw "Library loading not allowed" })();

Basically, it throws an exception if the library is not loaded from a local "resource://" page (hopefully considered as safe since it is part of the add-on code). I verified this prevented loading angular using the trick or if angular was inadvertently injected using a Firefox frame-script (nsIFrameScriptLoader.loadFrameScript) and add-on sdk/page-mod or sdk/content/worker modules.

Can we consider it is safe to use angular 1.x only from local add-on panels to run the user interface ?

Re: Angular 1.x Banned from Firefox Addons

#179

Post by AgentME » Thu, Oct 20, 2016, 10:35 PM UTC

adrin2 wrote: post #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 s…

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

Re: Angular 1.x Banned from Firefox Addons

#180

Post by the8472 » Thu, Oct 20, 2016, 10:36 PM UTC

AgentME wrote: post #176

the8472 wrote: post #172

Earlier quoted context omitted.

> 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, loa…

You can't run code that depends on variables in the page context though. If all the input values are serializable, then you can postMessage them into the iframe too, but you can't serialize objects with arbitrary methods, etc. The code you run in the sandbox can't return back a rich object with arbitrary methods because that has to get serialized back out. You can't use getters and setters to transparently proxy all…

Access to arbitrary methods would go against the idea of sandboxing anyway. If something references the global object for example you suddenly would have access to a privileged fetch API or other extension APIs.