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