Malware in the browser: how you might get hacked by a Chrome extension • Hacker News Board

Re: Malware in the browser: how you might get hacked by a Chrome extension

#61

Post by gnicholas » Wed, Jul 20, 2016, 9:40 PM UTC

JadeNB wrote: post #60

gnicholas wrote: post #54

My company has a Chrome/Firefox extension with ~60k users. We have been approached repeatedly by companies that want us to add in their tracking snippet to our extension. What they offered—tens of thousands of dollars every year—was tempting, but we didn't take the bait. They were opaque with us about what the code did (they didn't share the actual code without NDA, and we never got that far). But I did get to see th…

> I googled some phrases from the privacy policy insert and found that they had in fact gotten several extensions to include the code. Scary. Could you share those phrases, so that we can do the same Googling?

Looks like someone already did: https://www.reddit.com/r/programming/comments/3tgiaj/chrome_...

Leave off "site:chrome.google.com" and see a few more results. Looks like they don't have many takers these days (or have updated their privacy insert to make it harder to find them all).

Re: Malware in the browser: how you might get hacked by a Chrome extension

#62

Post by levisdown » Fri, Jul 22, 2016, 1:40 AM UTC

Minified code, even once pretty printed, is hard to read (especially since most minification tools rename function and variable names to single letters). Which causes the guidebook assessment even much harder, for no apparent performance obtain. http://www.crazysales.com.au/ So, in essence, I think that those are some good policies. It's just insufficient to have a policy in place if you're waiting for abuse reports to come in, because it still lets people get infected. Before anyone can install the extension, It'd be much better to apply them.

Re: Malware in the browser: how you might get hacked by a Chrome extension

#63

Post by jamiesonbecker » Fri, Jul 22, 2016, 7:17 PM UTC

tokenizerrr wrote: post #15

jamiesonbecker wrote: post #10

This article actually indicates a (probably bug-bounty'able) flaw in the Chrome webstore security checks: > The script that it fetches from the above server is a malware payload. The extension needs to download it after having been installed because it cannot ship with the payload if it wants to pass through the Chrome Webstore’s security checks. There probably are legitimate reasons to pull in remote content, but I…

I don't get where you're going with this. The extension has the " " permission which explicitly allows it to do this. It also explicitly turned on unsafe-eval.

> The extension has the "" permission which explicitly allows it to do this.

have nothing to do with the browser's normal Same Origin Policy for individual web pages. All URL's indicates that the extension is allowed to operate on all pages loaded in the browser window.

It has nothing to do with the resources loaded by the extension. In other words, I'm talking about (for a start), this "Regular web pages.. limited to Same Origin Policy. Extensions can talk to remote servers outside of its origin."

https://developer.chrome.com/extensions/xhr

In other words, extension should be treated as operating within the context of that tab; in other words, a locked-down sandbox for that tab.

Cross-origin permissions as noted above should be flagged to the user and should apply across the board to any injectable resource (including CSS, HTML, Javascript, SVG, etc.)

Otherwise, outside resources should fall into the Same Origin Policy (i.e., if your tab is at https://google.com/, only resources should be loaded from google.com.)

specifically refers to whether the extension is triggered on all URL's that are visited in the browser or not. That permission is usually needed.

Different origin attempts to communicate (read and/or write) any data on its own to any third party server should fall under different permissions.

For more information on what should have happened here, please see "Only local script and and object resources are loaded":

https://developer.chrome.com/extensions/contentSecurityPolic...

> It also explicitly turned on unsafe-eval.

That's a good point, and I agree; in fact, unsafe eval should be only be allowable within the Same Origin Policy.

Also, this brings up another good point: some permissions are more risky than others (for example, the legitimate use cases for unsafe eval are few). A visual indicator of the relative severity of the requested CSP's when installing the extension would probably help less technical people separate when an extension is very risky. (Multiple red danger symbols would probably be a good clue..)

Re: Malware in the browser: how you might get hacked by a Chrome extension

#64

Post by tokenizerrr » Fri, Jul 22, 2016, 7:43 PM UTC

jamiesonbecker wrote: post #63

tokenizerrr wrote: post #15

Earlier quoted context omitted.

I don't get where you're going with this. The extension has the " " permission which explicitly allows it to do this. It also explicitly turned on unsafe-eval.

> The extension has the " " permission which explicitly allows it to do this. have nothing to do with the browser's normal Same Origin Policy for individual web pages. All URL's indicates that the extension is allowed to operate on all pages loaded in the browser window. It has nothing to do with the resources loaded by the extension. In other words, I'm talking about (for a start), this "Regular web pages.. limited…

Yes, regular pages are limited to their same origin policy. Extensions, when they request it, are not. This extension requested it, so it is capable of downloading files from any server to a string. It also requested unsafe-eval, this lets it eval a string. Now, when you add one and one together, you have two features combined in a malicious way. But not a bug.

Sure, things should be different. But they are the way they are, and considering the way they are, this is not a bug. And certainly not bug-bounty'able.