Hacker News Reader

Comment by amluto | Hacker News Reader

VSCode’s entire security model is bananas. As far as I can tell:

The client and its scripts and plugins get unrestricted access to the remote system.

The code you’re editing (if not in restricted mode) gets full access to the system it’s on (which is IMO an unfortunate default but not surprising — it’s really time for development systems to wake up and sandbox the code being developed to at least be limited to its own directory tree, but that’s a different story).

The code you’re editing (if not in restricted mode) and remote plugins (no prompt at all AFAICT) get effectively full access to the client system, subject only to whatever privileges the client itself has. Yes, you read that right, if you Remote-SSH into a machine, that machine immediately owns you. Microsoft knows, and they do not care.

See, for example, https://github.com/microsoft/vscode-remote-release/issues/66...

View on HN

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?

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 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.

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 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.

I mean if VSCode is wrong then Vim and Emacs are condemned to an eternity of hell. I think there's a culture of editors being powerful in this way to a fault, on purpose. I think that's why devs like them— the training wheels, guard rails, seatbelts are all off.

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.)

Reply on news.ycombinator.com