VS Code extensions are less secure than browser extensions or even NPM packages | Hacker News Reader

VS Code extensions are less secure than browser extensions or even NPM packages

baldurbjarnason.com

40 pointscdme8 comments

This is the main thing that makes me uneasy about using neovim distributions. So many random extensions get installed.

I always think in the back of my mind "if someone compromised nvm-cmp or something we would all be so screwed". That's why I'm very happy to see the core team trying to bring those essential LSP and Completion packages into neovim core.

Indeed. One should always disable extension auto updating. Besides that, there’s not really any less security than NPM packages. It’s the open secret of the whole industry that we just open ourselves to RCE every day because the alternative (vetting dependencies) is too annoying.

<< If you don't want VS Code to even check for updates, you can set the extensions.autoCheckUpdates setting to false. >>

https://code.visualstudio.com/docs/editor/extension-marketpl...

VS Code everything is comically insecure. As far as I can tell, if you use VS Code Remote SSH or remote tunnels, the repository you open can execute code on the remote and the local machine, and the remote machine’s configuration can execute code on the local machine. And this is essentially by design, and MS doesn’t care.

At least VS Code in a browser is no less secure than the browser itself, at least as far as attacks against the client are concerned.

> As far as I can tell, if you use VS Code Remote SSH or remote tunnels, the repository you open can execute code on the remote and the local machine, and the remote machine’s configuration can execute code on the local machine

You're describing what is a feature of remote tunnels, though. Ability to executing code and commands is the entire point.

By default no local code execution is allowed when you open an unknown workspace btw: https://code.visualstudio.com/docs/editor/workspace-trust

> You're describing what is a feature of remote tunnels, though. Ability to executing code and commands is the entire point.

Excuse me? Editing code is the entire point. A major, but still secondary, point, is building and running code on the remote machine.

Running code on the client is certainly pointy, but I don’t think it’s “the point” at all.

> Editing code is the entire point. A major, but still secondary, point, is building and running code on the remote machine.

I don't think so. Building and running on the remote are the point.

Why would I want to remote somewhere just to edit some text files?

Running things on the remote opens up loads of possibilities, from leveraging more powerful hardware to building+running on an architecture different from my local env, including not having to keep a collection of dependencies on my machine and dealing with virtualenvs or whatever is their equivalent in the language I'm coding on.

I think that you and tredre3 are entirely missing the problem — you seem to be assuming that vscode works the way that any sensible person would assume that it works. Of course VS Code runs things remotely. Of course running an untrusted project on a remote machine runs code on the remote machine. This isn’t the problem.

The problem is that the remote project can run code on the client front end. You can create a brand new cloud machine, give it no particular permissions, run vscode on your laptop, connect to the remote machine via the remote extension, and load some compromised package npm package, and you expect that the damage is limited to the remote machine. And you would be wrong! The npm package can execute code on your laptop or borrow your ssh credentials, and MS doesn’t even consider this to be a bug!

https://github.com/microsoft/vscode-remote-release/issues/66...

Reply on news.ycombinator.com