How Malicious extensions hide running arbitrary code | Hacker News Reader

How Malicious extensions hide running arbitrary code

palant.info

75 pointssupermatou8 comments

I have so many questions after reading this. Like this example:

    [
      // Call console.log
      "@", [".", ["console"], "log"],
      // Verbatim call parameter
      "hi"
    ]

What sort of sandboxing model is susceptible to this?

I can't imagine any sort of principled sandboxing model that would be susceptible to running a whole interpreter within. Protections should go on the equivalent of syscalls, the side-effects code can have. We've known this for -- conservatively -- 30 years. Can somebody with knowledge explain how these extensions are breaking Chrome's security sandbox?

The bar for extensions is lower than breaking the browser security model. The goal is to slip basic XSS attacks past the Chrome Web Store review process, which is a mix of automated and human linters.

People over-pemission chrome extensions all the time, so you can execute arbitrary JS on any site you want once the user clicks ok. Why bother finding security sandbox exploits when users hand you the keys without thinking.

The extension platform is trying to further isolate extensions, but Google's profit motive is in its own way. See: MV3 and the response.

If Chrome offered an ad-blocker built in to the browser -- and maybe a privacy-blocker too -- they could eliminate the entire extension platform and solve the problem.

Even firefox doesn't offer a built in ad-blocker.

Opera on mobile does offer some sort of an adblocker built in.

However as it is a commercial company and free product, not sure what are the tradeoffs for using Opera.

I would prefer the extension platform to allow users to explicitly control what origins an extension is allowed to be active on, overriding the extension manifest. This should be the default, and allowing an extension for all origins or wilcard origins should require a mandatory prompt indepenent of the installation process.

Yes, extension privileges are creepy and an ad blocker (ublock origin only, to be exactly) is the only extension I intentionally allow to act on all websites on my behalf. Which is a conscious tradeoff.

There are other useful extensions though, and I'd prefer a common permission architecture with frequent prompts to the current take-it-or-leave approach.

I would disagree that adding an ad-blocker and a privacy blocker would eliminate the entire extension platform. There is still legitimate space for text manipulation extensions such as LanguageTool, form autofill managers (e.g. for canned responses), debug tools (so that I can see e.g. the FPS counter of the rendering process), citation formatters, site-specific data export tools (I am looking at you, ChatGPT), and so on.

Note: I’m the author of this article.

We aren’t talking about breaking out of the sandbox here, the extension sandbox stays intact. The problem is that this sandbox has plenty of privileges. And so Chrome attempts to restrict what code runs in this sandbox.

Technically speaking, they succeed – only the extension’s own code runs inside the sandbox here. But this is a mechanism aimed at preventing security vulnerabilities, not at combating outright malicious extensions. An extension can always download some data guiding its decisions. These extensions take it to the extreme, essentially turning that data into code.

This is fascinating. Especially that they're essentially using a little diy lisp to get around content security policy.

Reply on news.ycombinator.com