Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our Copyfish extension was stolen and adware-infested

a9t9.com

Post reply on HN
Print view View original

181–190 of 217 posts

Re: Our Copyfish extension was stolen and adware-infested

#181

Post by mustacheemperor »

krackers wrote: post #103

I guess this is as good a place as any to post that I noticed something similar had happened to [User-Agent Switcher for Google Chrome]( https://chrome.google.com/webstore/detail/user-agent-switche... ) and [Block Site]( https://chrome.google.com/webstore/detail/block-site/eiimnmi... ). The "report abuse" link on the page is useless. The former is very insidious in that it actually hides the malware in a .jpg file th…

Wow, I went to try and add a 1-star review to each to warn users (since both have extremely high ratings) and you need to install the malware-ridden extension to leave a review.

So we have a web store that that average Chrome users think is "safe," especially when apps have high review scores, and no meaningful ability to report malware to Google or to the users. Nice.

Re: Our Copyfish extension was stolen and adware-infested

#182

Post by QAPereo »

krackers wrote: post #103

I guess this is as good a place as any to post that I noticed something similar had happened to [User-Agent Switcher for Google Chrome]( https://chrome.google.com/webstore/detail/user-agent-switche... ) and [Block Site]( https://chrome.google.com/webstore/detail/block-site/eiimnmi... ). The "report abuse" link on the page is useless. The former is very insidious in that it actually hides the malware in a .jpg file th…

Are there any known problems with Random User Agent?

Re: Our Copyfish extension was stolen and adware-infested

#183

Post by horsawlarway »

occultist_throw wrote: post #175
gorhill wrote: post #161

Earlier quoted context omitted.

> it actually hides the malware in a .jpg file that appears benign at first (promo.jpg for anyone who wants to analyze) but when loaded in a canvas element and decoded in some manner I am guessing the extensions had a "content_security_policy" key in its manifest[1], with a 'unsafe-eval' CSP directive in its value? Any extension which declare such CSP directive in its manifest should be presumed malicious until furth…

So how does unsafe-eval and loading scripts dynamically pass any sort of "google security scan"? It would seem obvious that the moment a script tries to load arbitrary code outside of the package, it should fail.

Because unfortunately many, many libraries and templating engines rely on evaling code.

Generated code is code that's outside of the package.

There are also a few (keyword: FEW) valid reasons for using eval in situations where it's beneficial to pull updates and modules from a known and trusted location.

In those cases though, if you're not signing server side and validating signatures in the extension with a pre-shared cert, you've still got problems (single MITM attack can compromise your extension going forward).

Long story short, eval is still a very useful feature. It needs to be used properly, and it should be used rarely, but it's incredibly powerful, and lots of things you don't really think about suddenly stop working if it goes away.

Re: Our Copyfish extension was stolen and adware-infested

#184

Post by livingparadox »

jeswin wrote: post #88

Chrome's security policy is surprisingly poor and is the reason why I stay away from most extensions. "Read data from all websites" is like root on the phone. It should be allowed only via deliberate, explicit user action. While this will be an interesting UX challenge, defaulting to domain-specific permissions is the sane thing to do in this age. Case in point, I don't care about a readability or bookmarking plugin…

There's a good flag to make "Read data from all websites" more reasonable.

chrome://flags/#extension-active-script-permission

It requires a "deliberate, explicit user action" to run the extension on the page each time even if it asks for that permission. And if you really do want an extension enabled 24/7 (such as vimium), then you can select a check box in the extensions page which allows the extension to run without specifically enabling it each time.

Re: Our Copyfish extension was stolen and adware-infested

#185

Post by cyphar »

Endy wrote: post #120
driverdan wrote: post #56

Earlier quoted context omitted.

> The lesson here is: never trust anyone or anything. Which is why you should use 2FA and why you shouldn't trust someone who says they don't use it.

I don't trust any of the 2FA providers. And I have neither the time nor the interest to try and learn to code it in binary.

TOTP is a specification and there are many free software implementations. U2F is also a specification (but generally they aren't free software implementations).

Re: Our Copyfish extension was stolen and adware-infested

#186

Post by occultist_throw »

horsawlarway wrote: post #183
occultist_throw wrote: post #175

Earlier quoted context omitted.

So how does unsafe-eval and loading scripts dynamically pass any sort of "google security scan"? It would seem obvious that the moment a script tries to load arbitrary code outside of the package, it should fail.

Because unfortunately many, many libraries and templating engines rely on evaling code. Generated code is code that's outside of the package. There are also a few (keyword: FEW) valid reasons for using eval in situations where it's beneficial to pull updates and modules from a known and trusted location. In those cases though, if you're not signing server side and validating signatures in the extension with a pre-sha…

Indeed they do. I can think much of the NPM ecosystem which assumes (incorrectly) that packages are unique, stable, and good. That whole situation a while back showed that not to be the case.

I'd be OK with grabbing code elsewhere, as long as I could guarantee that it would never change. Primarily, immutability. I'm thinking of something like an IPFS repo which is "elsewhere", but still very much crawl-able, scannable for bad stuff (aside turing issues...), and can be shown to reproduce stuff if it is broken.

Also, using an immutable self-certifying system would also solve the second point, regarding the single MITM. The trust would be with the file/package, and not some ephemeral cert (whos trust is brokered from above).

Re: Our Copyfish extension was stolen and adware-infested

#187

Post by rsync »

jeswin wrote: post #88

Chrome's security policy is surprisingly poor and is the reason why I stay away from most extensions. "Read data from all websites" is like root on the phone. It should be allowed only via deliberate, explicit user action. While this will be an interesting UX challenge, defaulting to domain-specific permissions is the sane thing to do in this age. Case in point, I don't care about a readability or bookmarking plugin…

"Chrome's security policy is surprisingly poor and is the reason why I stay away from most extensions. "Read data from all websites" is like root on the phone. It should be allowed only via deliberate, explicit user action."

What we really, really need is the ability to jail (and tie to a different IP) a browser instance.

I want this so much that I am somewhat seriously considering learning the syntax of the vmware fusion command line tool so that I can quickly fire up a browser VM with just a command (and revert state to "clean" snapshot, etc.).

The problem, of course, is that this use-case is so compelling that in a short amount of time I would have 5 or 6 browser VMs running and now I am running out of memory ... it's silly to fire up an entire virtual machine just to run the browser.

However, the existing sandbox measures are not nearly enough. I want to do my banking from a different IP than I use google services from. Every day I want to wipe that OS to clean state and start over.

This is not an easy configuration. Even with an OS (FreeBSD, Solaris) that has jail it's not simple to locally interact with a GUI tool on your existing desktop that is actually in its own jail ...

Re: Our Copyfish extension was stolen and adware-infested

#188

Post by logicallee »

likpok wrote: post #177
logicallee wrote: post #117

Earlier quoted context omitted.

Google is staffed by geniuses who also read HN and I feel it is sufficient that I suggested one possible correct solution here on HN. I am sure they'll introduce some solution to this problems. (I mean some way for them to disable compromised extensions centrally.) I am not personally an extension developer and don't run many.

The people you need to convince is Google management, so that they prioritize this over everything else on the roadmap. One easy way to do that from outside is to make it actually a priority, by making it a PR issue. Otherwise it turns into one of those perennial 'things we want to do' that never beats out the critical items on the roadmap.

can you give a source for this insight? tell me more.

It does explain so much. for example all this work was put into a ridiculous, animated, moving, flashing new gmail sign-in page that was pre-announced for weeks (our sign-in page is changing!) and after all that work does not include even seven and a half minutes worth of improvement by a developer. For example, I had to laugh and laugh after I realized it wasn't accepting my password because my caps lock was on.

I would expect a popup warning if you have your caps lock turned on while typing. Because, you know, that is one of literally like 3 things you can do to improve a sign-in page that is that dynamic and moving and flashing. There's just not much to improve.

All that flash and it doesn't do anything at all. Your comment gives a lot of insight as to why so I would like to understand this cultural shift.

how does management work at Google now?

Re: Our Copyfish extension was stolen and adware-infested

#189

Post by logicallee »

IncRnd wrote: post #180
logicallee wrote: post #95

We should never have to read a title "disable immediately" by a developer. In a news article. That is not how this should be distributed, in case the original developer is the one distributing the news. Instead, Google should generate an emergency disable code that a developer can put into a simple web form from anywhere in the world, even if the developer has been locked out of every one of their accounts, which imm…

That is a good start but isn't sufficient. Many browsers exist on networks that are airgapped or are off of the Internet for extended periods of time. Plus, there are regulations or policies in many places that forbid this type of action.

Are we talking about the same thing? Chrome? Chrome literally auto-updates.

Re: Our Copyfish extension was stolen and adware-infested

#190

Post by horsawlarway »

occultist_throw wrote: post #186
horsawlarway wrote: post #183

Earlier quoted context omitted.

Because unfortunately many, many libraries and templating engines rely on evaling code. Generated code is code that's outside of the package. There are also a few (keyword: FEW) valid reasons for using eval in situations where it's beneficial to pull updates and modules from a known and trusted location. In those cases though, if you're not signing server side and validating signatures in the extension with a pre-sha…

Indeed they do. I can think much of the NPM ecosystem which assumes (incorrectly) that packages are unique, stable, and good. That whole situation a while back showed that not to be the case. I'd be OK with grabbing code elsewhere, as long as I could guarantee that it would never change. Primarily, immutability. I'm thinking of something like an IPFS repo which is "elsewhere", but still very much crawl-able, scannabl…

>I'd be OK with grabbing code elsewhere, as long as I could guarantee that it would never change.

But there are lots of times when the final result is much more valuable when the code CAN change.

You just have to have trust.

1. Trust that the folks who can change the code aren't malicious.

2. Trust that the code you think you're running is really the code you're running.

Neither of those things are really too much of a stretch. And the services and capabilities they allow are very, very nice.

Hell, statistically speaking... we're both typing these comments in Google Chrome, a browser that auto-updates itself all the time.

but 1. we trust that Google won't suddenly become malicious and 2. we trust the mechanisms in place (https, cert pinning) to ensure the update is really the update Google sent.

In fact, this whole article actually boils down to a breakdown of trust: Turns out random extension devs aren't as trustworthy as we might like. They make mistakes and there's no safety net.

Post reply on HN