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.

[0] http://angularjs.blogspot.com/2016/09/angular-16-expression-...

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

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.

That sounds like an unfair advantage over smaller competitors to me.

Yes. Fair is often not optimal.

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

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.

Note that the github discussion is about Firefox webextensions, which have the same security model as Chrome extensions (and in fact aim to be API-compatible with Chrome extensions).

Chrome has many many extensions which run on and modify the page DOM just like Firefox! I think it might even be reasonable to guess that around half of extensions do this.

Modifying DOM is not enough to cause a vulnerability. In Chrome content scripts (the ones that are injected into a page from an extension) have limited privileges though there still can be the ways to exploit them.

Chrome content scripts can have permissions to make AJAX requests to any origin. Sure, it's not a straight-ticket to getting code native execution and installing malware on your machine, but it means an exploit against an extension with wide enough permissions could harvest your email and bank info.

It's completely expected to both inject scripts into a pages DOM, and also to set up a communication channel back from the page content script to the central extension "process". It's not a rare corner case. An ad-blocking content script might want to report user-selected extra filter requests back to the main adblocker context; or it may simply want to count the number of blocked requests; or a password manager may want the ability to save new passwords; etc.

Typically, you'd expect the central extension to trust messages it receives from its own content scripts, so even though there is a separation between the extension and the pages it's on, the separation is by no means a leak-proof security measure; it cannot be. You rely on each and every such extension being carefully written and having no security relevant bugs.

If you think about it, it should be clear that it's practically infeasible to fix this hole. Extensions authors simply need to avoid such bugs. If angular1 somehow makes it easy for them to make mistakes when used by an extension, that's a problem.

>UPD: @bzbarsky noted that Firefox...

Don't update your post to include replies to your own comment. Hackernews already allows us to see the replies. If you have a response to a comment, reply to that comment.

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 emails and do things like steal data or change your passwords.

The discussion here is about Firefox webextensions, which use the Chrome extension API and are not supposed to be more powerful than Chrome extensions.

Ah that wasn't clear so I assumed it was addons in general. Thanks.

>IIRC Firefox addons are significantly more powerful than Chrome extensions

I think that is only if you use the C++ API and that this post is talking about their JavaScript API.

It's possible to write Firefox extensions in JavaScript that are a lot more powerful than Chrome extensions (or webextensions, which are the Firefox equivalent of Chrome extensions) are. That capability is slowly being phased out, though.

> I think that is only if you use the C++ API

No, historical XPI addons are in JS (and XML and CSS). While they can bundle native code most don't, but they run in at the same privilege level as the browser itself (consider Firebug, which was and still is an addon).