Sorry, do you mean to say if I download untrusted code and open it in VSCode to inspect it, said code can pwn my system?

(Forgive me if this question sounds uninformed, I haven't used VSCode much, but if true this would not be behavior I expect from a code editor).

Yes, if you click yes when asked if you trust it.

But it’s worse: if you download untrusted code onto a remote machine or VM and then open it via VSCode’s SSH feature, it can own your local system.

It's not a sandbox and not intended to be.

If you don't trust your own dev VM, why do you use it for development? Why do you connect? If you clone any random repository and click "trust this" - what do you expect to happen?

If I want to edit code I don't trust, it would be entirely sensible to stick it on a throwaway VM and SSH to it. Except that VS Code entirely screws this up.

As far as I know, even if you don't tell it you trust the code, the mere act of SSHing to the system blows up the trust boundary, and malicious contents of ~/.vscode on the target machine can get RCE on the client machine.

And I want to connect because VSCode is a fairly nice editor and the actual Electron application works a bit better than the webpage version. But the Electron application can't bother to sandbox itself and doesn't have a security model, so there you go.

I often connect to my remote servers because they have a problem. If a machine has a problem I can ssh into it and inspect it without worrying about my localhost. If I used vscode, I have to also be lucky, which is not a good security assumption.

The main thing would be supply-chain attacks designed to execute code on developer boxes. ideally, a dev VM or container that gets pwned wouldn't be able to immediately start exfiltrating all the secrets on your machine, just whichever ones you've given to the dev environment, which are probably fewer than "all of them."

I wouldn't expect the remote daemon to have full access. Should be running under the associated user account. However, if installed with privileges (via sudo, etc) to persist long-term, well you get what you asked for.

Compromising your user account is pretty bad. Let's see:

- Often gets your SSH key. Certainly gets to use your SSH agent.

- Can easily persistently compromise your web browser.

- Can trivially exfiltrate all your data.

- Has a good chance of being able to run 'sudo'.

- Can generally break Mac OS's sandboxing. (There's no shortage of examples demonstration that Apple really doesn't try very hard to make Mac OS resist attack by programs that are sort-of-sandboxed.)

- Gets all of your privilges for all of your fancy cloud services: GitHub, your favorite cloud's admin page, your email, slack, etc.

Saying "but it wasn't root" is not much comfort, nor is it even necessarily true.

It’s running on the remote machine, so these do not apply by default. Sudo requires a password.

I forgot to mention that the client software does have access to your user account on the local machine as well. That's always been the case with just about all software. These days one must look into a local firewall and sandboxing for further protection.

This is, frankly, absurd. I have literally never, in my entire time using VSCode with Remote-SSH, wanted the repository or an extension or anything at all in the whole IDE to have any sort of access to my client machine with the possible exception of reading my VSCode config. No files in my home directory, no network, no anything.

(Some people may like VSCode to forward a port to get a local web browser to target the remote machine. Fine, make that an option. I, personally, prefer to forward the port myself.)