26 ms·

> 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

> 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 further thorough investigation proves otherwise. The 'unsafe-eval' in a manifest is essentially the ability for an extension to execute arbitrary code in the extension context which can't be code-reviewed by reading the source files. EDIT: "User-Agent Switcher for Google Chrome" confirmed to have a 'unsafe-eval' in its manifest. "Block site" does not declare 'unsafe-eval' in its manifest. It does however add many "script-src" directives in its manifest, including one for ".wips.com", which means the extension can pull javascript resources not bundled with the extension from its own web site (hence outside of the Chrome store review process if any), and thus the behavior of the extension is subject to change at any time as far as its permissions allow. So I guess the suspicion should be extended to any extension declaring a "content_security_policy" key in its manifest. === [1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/content_security_policy https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ma...

occultist_throw 9y ago
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.
- horsawlarway 9y ago
  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.
  - occultist_throw 9y ago
    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).
    - horsawlarway 9y ago
      >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.
    - eridius 9y ago
      If it can't change, then what's the point of grabbing something elsewhere instead of just embedding it in the addon?
  - gorhill 9y ago
    > 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 users at heart. I would like to be shown an actual, real case of why eval() would be impossible to avoid for an extension, not just a theorized one with no real sensible and convincing example. As much as I try, I can't come up with any such scenario. [1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/content_security_policy https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ma...

occultist_throw 9y ago

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.

horsawlarway 9y ago
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.
- occultist_throw 9y ago
  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).
  - horsawlarway 9y ago
    >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.
  - eridius 9y ago
    If it can't change, then what's the point of grabbing something elsewhere instead of just embedding it in the addon?
- gorhill 9y ago
  > 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 users at heart. I would like to be shown an actual, real case of why eval() would be impossible to avoid for an extension, not just a theorized one with no real sensible and convincing example. As much as I try, I can't come up with any such scenario. [1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/content_security_policy https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ma...