Live data from Hacker News

Our Copyfish extension was stolen and adware-infested

a9t9.com

201–210 of 217 posts

Re: Our Copyfish extension was stolen and adware-infested

#201
post #192

Earlier quoted context omitted.

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

My point is that Chrome cannot always auto-update for all installations. From that standpoint I made the comment that an Internet based revocation code may not be sufficient, and disclosures/notifications will still need to be monitored by administrators.

orgs running such ridiculous setups can monitor revokes coming over the wire from google and selectively apply them themselves, if they just care about their busy-work jobs sitting reading security bulletins. I don't really care about the security of their made-up non-jobs and google shouldn't either. they can do what they like.

Re: Our Copyfish extension was stolen and adware-infested

#202

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…

> Long story short, eval is still a very useful feature. And yet this is Mozilla's stance regarding extensions pulling code from outside the extension's own package[1]: > extensions with 'unsafe-eval', 'unsafe-inline', remote script, or remote sources in their CSP are not allowed for extensions listed on addons.mozilla.org due to major security issues. This is the sane stance in my opinion, with the best interests of…

You're really unable to come up with a single example of why treating data as code isn't useful?

I mostly agree with you, eval is dangerous and often improperly used, but it's ALSO an incredible tool.

The complete opposite of your argument is languages that are homoiconic(https://en.wikipedia.org/wiki/Homoiconicity): They're built in a way that explicitly allows manipulation, even of the language itself as a FEATURE.

They include languages like Lisp/Clojure/Julia.

Worse, many of the ways to "work" around the lack of eval just reduce the attack surface, or make the attack considerably less likely (obfuscation not security!).

Simple case: You need to apply certain policies to certain sites, those policies vary based on the browser in use, the country of origin of the user, and the country the site is hosted in.

The way that those policies vary... ALSO varies. As new legislation is passed, or corporate policies change, or certain countries become more or less stable.

A (completely valid) way to solve this problem would be to send both a policy engine and a policy set to the extension. The policy engine is eval'd and runs the policy set.

That allows real-time updates to the deployed extension's ability to parse new policies. Not just different data in the policies, mind you, but actual new policy capabilities.

Do you have to use eval? Nope, sure don't. You can generate a custom ebnf (hell, why not just use the ebnf for ecmascript), write you own freaking engine, and run it. All without eval. But you're still just running eval. You just get to name it nicely to something else, introduce an incredible amount of overhead to recreate a feature someone has already provided, and generally get less performant results.

Or, you can just fucking sign the payload with a pinned cert and verify on the client, and get the same guarantees for security you have with HTTPS to begin with.

Re: Our Copyfish extension was stolen and adware-infested

#203

Earlier quoted context omitted.

> Long story short, eval is still a very useful feature. And yet this is Mozilla's stance regarding extensions pulling code from outside the extension's own package[1]: > extensions with 'unsafe-eval', 'unsafe-inline', remote script, or remote sources in their CSP are not allowed for extensions listed on addons.mozilla.org due to major security issues. This is the sane stance in my opinion, with the best interests of…

You're really unable to come up with a single example of why treating data as code isn't useful? I mostly agree with you, eval is dangerous and often improperly used, but it's ALSO an incredible tool. The complete opposite of your argument is languages that are homoiconic( https://en.wikipedia.org/wiki/Homoiconicity ): They're built in a way that explicitly allows manipulation, even of the language itself as a FEATUR…

"Treating code and data" doesn't specifically require eval. Lisp macros avoid eval. Dynamic extensions to a running Lisp program don't require eval, but rather load.

Re: Our Copyfish extension was stolen and adware-infested

#204

Earlier quoted context omitted.

You're really unable to come up with a single example of why treating data as code isn't useful? I mostly agree with you, eval is dangerous and often improperly used, but it's ALSO an incredible tool. The complete opposite of your argument is languages that are homoiconic( https://en.wikipedia.org/wiki/Homoiconicity ): They're built in a way that explicitly allows manipulation, even of the language itself as a FEATUR…

"Treating code and data" doesn't specifically require eval . Lisp macros avoid eval. Dynamic extensions to a running Lisp program don't require eval , but rather load .

Sure, but you're still taking data from outside of your original package scope and running it or allowing it to be run later.

That's just useful. Javascript eval gets a bad rap (entirely in my own opinion) because

1. It's the de-facto language for the web, which both drastically increases the number of inexperienced developers, as well as the total attack surface.

2. Again, as a scripting language for browsers, parsing untrusted user input is a common need. Eval filled the need for parsing, but not the need for trust.

You can absolutely use eval in entirely safe ways. Most people don't, and doing so (especially in JS) is hard. That's because JS has made establishing trust hard. Juuuuust recently, with the introduction of some of the webcrypto work, and the rapid rise of ubiquitous https are we really getting to the point where doing so is really feasible at all.

Re: Our Copyfish extension was stolen and adware-infested

#205
post #196

Earlier quoted context omitted.

You're referring to this one right? https://chrome.google.com/webstore/detail/user-agent-switche... Is there any way to confirm that this is actually from google though, and not just some 3rd party who chose their publisher name as "google.com"? Most official google extensions have a "by google" badge in the right hand column whereas this one lacks it.

It's interesting, if you go to the support tab and follow the link to the maker's support website, you end up on https://spoofer-extension.appspot.com/ The contact page there links to "Glenn Willson" as the author - and their G+ page has a link to The User-Agent Switcher Has A New Owner: Google! http://www.glennwilson.info/2017/02/the-user-agent-switcher-... Now, is that trustworthy or not? Good question.

Search for an official Google Chrome extension (such as Chrome Remote Desktop). You'll see a 'By Google' logo (https://chrome.google.com/webstore/category/collection/by_go...) as well as an 'offered by google.com'.

This just has the 'offered by google.com'. I would have assumed a 'By Google' logo would have been added after acquisition?

Re: Our Copyfish extension was stolen and adware-infested

#206

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…

If it can't change, then what's the point of grabbing something elsewhere instead of just embedding it in the addon?

Re: Our Copyfish extension was stolen and adware-infested

#207

Earlier quoted context omitted.

I find it strange the team member clicked on the link. For such high value accounts, always use google or type in the URL. Why would you click?

And worst of all, it was a bit.ly link they clicked.

Can u paste this mail here ?

Re: Our Copyfish extension was stolen and adware-infested

#208
post #67

This is the second extension that I use on chrome that has been hijacked. The first was live http headers [0] I have never had this experience on Firefox. Is it simply a matter of Chrome being a bigger target? [0] https://www.webmasterworld.com/webmaster/4829365.htm

The Great Suspender Chrome extension was also phished https://github.com/deanoemcke/thegreatsuspender/issues/512

Typewriter sounds , Twitch window which always on top , one of the Youtube UI upgrade extension, but in this case author simply sell extensions to malicious company

Re: Our Copyfish extension was stolen and adware-infested

#209
post #196

Earlier quoted context omitted.

You're referring to this one right? https://chrome.google.com/webstore/detail/user-agent-switche... Is there any way to confirm that this is actually from google though, and not just some 3rd party who chose their publisher name as "google.com"? Most official google extensions have a "by google" badge in the right hand column whereas this one lacks it.

It's interesting, if you go to the support tab and follow the link to the maker's support website, you end up on https://spoofer-extension.appspot.com/ The contact page there links to "Glenn Willson" as the author - and their G+ page has a link to The User-Agent Switcher Has A New Owner: Google! http://www.glennwilson.info/2017/02/the-user-agent-switcher-... Now, is that trustworthy or not? Good question.

Well, the LinkedIn checks out too: https://www.linkedin.com/in/wilsong

Of course, forgeable as well.

I've sent an email to his anonymized domain registrant contact to see if he can do anything about his malicious competitor.

Re: Our Copyfish extension was stolen and adware-infested

#210
post #61

Earlier quoted context omitted.

This actually isn't true. A website like https://www.xn--80ak6aa92e.com/ won't show up as apple.com. Browsers don't allow Unicode rendering in the URL bar. Maybe IE is affected though. I haven't tested every browser. But it's a known security concern.

Sorry to tell you, does show up as apple.com in my browser. Chrome 52.0.2743.82-1 on Arch x86_64.

The IDN vulnerability was fixed by Google in Chrome 58.

https://arstechnica.co.uk/information-technology/2017/04/chr... https://bugs.chromium.org/p/chromium/issues/detail?id=683314

Why have you got such an old version of Chrome?

Post reply on HN