[secmax]

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

[codedokode]

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.

[bzbarsky]

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

[AgentME]

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.

[codedokode]

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.

[AgentME]

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.

[emn13]

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.

[hueving]

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

[masklinn]

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.

[AgentME]

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.

[bzbarsky]

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

[masklinn]

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

[jaredsohn]

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

[bzbarsky]

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.

[masklinn]

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