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

Re: Angular 1.x Banned from Firefox Addons

#101

Post by codedokode » Thu, Oct 20, 2016, 7:01 PM UTC

nathancahill wrote: post #45

Gigablah wrote: post #31

Earlier quoted context omitted.

In other words, the vulnerability is with Firefox instead of Angular?

Not necessarily. JS in addons has to run in a more privileged environment to interact with the browser. However, that makes it possible to write insecure addons. In this case, Angular 1.x might contain the insecure code. For example: arbitrary user input from a web page is passed to the addon. Angular handles it, and does "eval-like things"[0] with it. Now the attacker is running arbitrary code in a privileged enviro…

You can find same kind of "vulnerability" in jQuery:

    $(element).html(user input);

This will evaluate scripts in "user input". Does this mean jQuery is vulnerable? No, it just means you are doing something wrong with it.

UPD: I was wrong, jQuery inserts a script tag into DOM instead of directly calling eval() so the code above is not equivalent to eval and is another type of vulnerability.

Re: Angular 1.x Banned from Firefox Addons

#102

Post by mordocai » Thu, Oct 20, 2016, 7:05 PM UTC

codedokode wrote: post #100

AgentME wrote: post #44

Earlier quoted context omitted.

No, the vulnerability specifically has to do with Angular within extensions. Angular trusts the page DOM and uses eval-like functions on code within it. This is relatively fine if the DOM isn't controlled by someone else, but in cases where the DOM is controlled by someone with less permissions (ie. Angular is running in a higher-privilege extension, and the DOM is controlled by some webpage), then then an attacker c…

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.

Browser extensions in all browsers typically do things to the web page DOM for various reasons. I don't know how the technical details work since I've never written one, but chrome addons can certainly change things about the web page DOM.

Re: Angular 1.x Banned from Firefox Addons

#103

Post by bzbarsky » Thu, Oct 20, 2016, 7:11 PM UTC

codedokode wrote: post #101

nathancahill wrote: post #45

Earlier quoted context omitted.

Not necessarily. JS in addons has to run in a more privileged environment to interact with the browser. However, that makes it possible to write insecure addons. In this case, Angular 1.x might contain the insecure code. For example: arbitrary user input from a web page is passed to the addon. Angular handles it, and does "eval-like things"[0] with it. Now the attacker is running arbitrary code in a privileged enviro…

You can find same kind of "vulnerability" in jQuery: $(element).html(user input); This will evaluate scripts in "user input". Does this mean jQuery is vulnerable? No, it just means you are doing something wrong with it. UPD: I was wrong, jQuery inserts a script tag into DOM instead of directly calling eval() so the code above is not equivalent to eval and is another type of vulnerability.

It will evaluate scripts with the permissions of the element being manipulated. Which in a normal webpage is the same thing as the script doing the manipulating, which means you have XSS, which is bad, yes.

In the context of an extension manipulating a web page, though, the jQuery thing you quote will evaluate the script with the permissions of the web page, not the permissions of the extension. On the other hand, doing eval() with a string from the web page will evaluate things with the permission of the extension.

So there is a pretty subtle (and irrelevant in web pages!) but important distinction between the two kinds of script injection here. In a web page they are more or less equivalent in terms of leading to XSS if you have untrusted input. But in an extension, the jQuery one is OK if your input comes from the web page itself, and the eval() version is not.

[Disclaimer: I work for Mozilla, but not on extension policy.]

Re: Angular 1.x Banned from Firefox Addons

#104

Post by codedokode » Thu, Oct 20, 2016, 7:11 PM UTC

secmax wrote: post #91

TheRealPomax wrote: post #79

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…

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

Re: Angular 1.x Banned from Firefox Addons

#105

Post by vmasto » Thu, Oct 20, 2016, 7:14 PM UTC

omouse wrote: post #99

Animats wrote: post #95

Using big external libraries in Firefox add-ons used to be totally prohibited. Jquery used to be prohibited outright. It's an undesirable practice. Add-ons operate at a higher privilege level than web pages. The low-quality webcrap that can be tolerated on a web page has no place in a privileged add-on.

Agreed and this is why React has been given a pass I think, because it's only for display purposes.

Really it doesn't matter if it's for display purposes or not. It all boils down to implementation. I can make a view library riddled with XSS vulns in very little time.

Re: Angular 1.x Banned from Firefox Addons

#106

Post by bzbarsky » Thu, Oct 20, 2016, 7:14 PM UTC

codedokode wrote: post #100

AgentME wrote: post #44

Earlier quoted context omitted.

No, the vulnerability specifically has to do with Angular within extensions. Angular trusts the page DOM and uses eval-like functions on code within it. This is relatively fine if the DOM isn't controlled by someone else, but in cases where the DOM is controlled by someone with less permissions (ie. Angular is running in a higher-privilege extension, and the DOM is controlled by some webpage), then then an attacker c…

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 the web page, then doing:

  foo.somePropNameIMadeUp = 5;

will set a property that is not visible to the web page, while doing:

  foo.setAttribute("id", "myId");

or:

  foo.id = "myId";

will modify the DOM in a way the web page can see.

Re: Angular 1.x Banned from Firefox Addons

#107

Post by bzbarsky » Thu, Oct 20, 2016, 7:18 PM UTC

vladimir-y wrote: post #98

bzbarsky wrote: post #96

Earlier quoted context omitted.

Note that in the context of a browser extension an "XSS vulnerability" means "a web page just got to run code with the extension's privileges".... [Disclaimer: I work for Mozilla.]

I guess extension's privileges means more privileges than a regular web page has (accessing file system for example?), if so then it's even more dramatic.

Right. Extensions have more privileges than normal web pages.

For the specific case here (webextensions), the extension asks for a list of permissions at install time, so which privileges it has, exactly, depends on the extension. https://developer.chrome.com/extensions/declare_permissions has documentation on what the various permissions you can request are.

Re: Angular 1.x Banned from Firefox Addons

#108

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

codedokode wrote: post #100

AgentME wrote: post #44

Earlier quoted context omitted.

No, the vulnerability specifically has to do with Angular within extensions. Angular trusts the page DOM and uses eval-like functions on code within it. This is relatively fine if the DOM isn't controlled by someone else, but in cases where the DOM is controlled by someone with less permissions (ie. Angular is running in a higher-privilege extension, and the DOM is controlled by some webpage), then then an attacker c…

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.

This is an issue with extensions that run code on webpage DOM. It's very popular for extensions to modify webpages. Chrome supports extensions like this too. I might even guess that more than half of extensions do this.

>Why would anyone run Angular on a browser page? It would probably conflict with existing application.

Adding additional widgets or tools directly within an existing webpage is a common thing for extensions to do. And if you're adding a lot of UI, you might want to use an existing UI library like you would on a normal webpage instead of doing all the DOM by hand. Not all UI libraries work out well for this apparently.

Re: Angular 1.x Banned from Firefox Addons

#109

Post by ghurtado » Thu, Oct 20, 2016, 7:27 PM UTC

xxkylexx wrote: post #74

martey wrote: post #64

Earlier quoted context omitted.

If you're the engineer in question (since your comment history suggests you work at Bitwarden), you should explicitly state that and explain that ignoring any vulnerability was not the intent of your comment.

Thanks. I updated the comment.

It's not doing much for your reputation (or that of your employer) that you still haven't clarified whether you are the engineer or not - even after deliberately referring to yourself in the third person and being called out for it.

Re: Angular 1.x Banned from Firefox Addons

#110

Post by jMyles » Thu, Oct 20, 2016, 7:27 PM UTC

moron4hire wrote: post #33

yc-kraln wrote: post #16

"we were not able to report them to angular as the security researcher who found them asked us to not share them." Nice.

I read that and said a literal WTF. How is it at all acceptable to honor such a request? What possible good reason could there be? Unless the discloser was the US Government and the request was actually a court order. But this seems ludicrous. If they require secrecy around the exploit, they wouldn't have disclosed it to Mozilla at all.

> Unless the discloser was the US Government and the request was actually a court order.

If this were the case, I think it's actually the best reason to disregard the request of the discloser and disclose, as it's now in the public interest (ie, closing a possible backdoor being used to surveil dissidents, etc), not merely part of a private agreement.

But yeah, if mozilla signed an NDA on this, that seems like it was a bad move from the get-go.