Document the security model of VSCode Remote Development

[zzh1996]

There is currently no documentation of the security model of VSCode Remote Development.

If the remote server is fully controlled by an attacker, is it possible for him/her to run arbitrary code on my local machine? Is there any PoC for this?

If the answer is yes, does Restricted Mode solve this problem? In my understanding, Restricted Mode only stops attacks from the project folder, while the attacker could also manipulate the vscode server.

[jeremyn]

I agree with the need for improved security documentation.

Another example: dev containers can act as a sandbox to protect against certain supply chain attacks like the recent incident with the node-ipc and peacenotwar npm packages. However, if you install an SSH client into your container, VS Code Remote-Containers will quietly set up SSH agent forwarding. This includes using any of the official Microsoft dev containers since they all include an SSH client. Exposing an unlocked SSH agent to code that a user might consider hostile is probably not what that user wants.

So, it would be helpful to know VS Code's security design goals as far as using dev containers to isolate code from the host. If any VS Code update could include some change that breaks isolation, then there's not much point in a user trying to lock it down. But this is something that the VS Code documentation should make clear, rather than letting each user try to figure out the team's intentions.

@zzh1996 I'm not an expert, but skimming some of the documentation -- Remote Development FAQ, Supporting Remote Development, Extension Host -- it looks like an extension could tell VS Code to run it on the local machine instead of on the server, and then malicious code on the server could modify .vscode/settings.json or something on the server to trick the extension into doing something bad on the local machine. The "Extensions" section of the workspace trust documentation you linked suggests that the extension author needs to decide if their extension is exploitable instead of, say, VS Code requiring dangerous actions to go through certain key paths and then locking those paths down. Some clarification from the VS Code team would be good.

[jeremyn]

As a specific example, it looks like if you have a remote situation like:

• Windows local machine < Remote-SSH (Ubuntu 20.04) < Remote-Containers (Ubuntu 20.04), and
• you install gnupg into the container, and
• gpgconf is missing from the SSH host, and
• you have gpgconf in your Windows path and %userprofile%/.gnupg on your Windows local, then

Remote-Containers will copy your public key information from your Windows local into the container: Start: Run in container: # Copy c:\Users\<me>\.gnupg\pubring.kbx to /home/<me in container>/.gnupg/pubring.kbx and similarly for trustdb.gpg. @chrmarti's comment at #6566 (comment) suggests Remote-Containers is going to attempt some kind of forwarding, which I can understand from the container to the SSH host, but not from the container directly (?) to the Windows local. gpg in the container doesn't see any secret keys (gpg --list-secret-keys), nor can I can't sign anything in the container (echo test | gpg --clearsign), getting some No secret key messages.

Perhaps there's a bug involved, I'm not sure. In any case, this isn't quite "arbitrary code" but it's pretty dangerous, considering that a public key database can be extremely sensitive and here VS Code is copying it into an environment I've double-sandboxed in a container on a remote (VM) host.

I'd be interested in hearing what the security thinking ("model") is behind this behavior. Actually: I suspect remote development was originally designed with the idea of developers working on relatively untrusted workstations reaching out to trusted internal networks. In that case, the remote system would be at least as trustworthy as the local system, so the remote system causing something to run on the local system would not really be a security concern.

[alexdima]

Thank you for these good questions! For VS Code remote, the VS Code server is in the same trust boundary as the VS Code client. That means that you should only connect to VS Code servers that you trust. So you should only connect to SSH machines that you trust and only create dev containers from definitions that you trust (i.e. you should not use dev containers as a sandbox).

For Remote Containers, we handle trust using VS Code's UI, for example we create dev containers only from definitions which come from a trusted folder, we prompt and ask for trust before creating a dev container from a git repository URL, etc.

For Remote SSH, we include the following notice in the extension README:

[jeremyn]

@alexdima Thanks, however I don't think that warning is clear enough to cover the node-ipc/peacenotwar example, or that putting the responsibility for trust entirely onto the user is fair. In any case it seems like the only way to really be sure is to sandbox VS Code itself.

[alexdima]

I agree. That's why we have this (very related) item on our roadmap -- https://github.com/microsoft/vscode/wiki/Roadmap#security

Doing parts of this is a prerequisite in order to allow supporting connecting to untrusted servers.

[jeremyn]

@alexdima I'm not sure that covers it. For example node-ipc is installed as a dependency of vue-cli which is included in a Vue devcontainer Microsoft provides through Remote-Containers, and in a Vue/VS Code tutorial on the VS Code website. If this means users should consider stuff from Microsoft to be untrusted then I think "trust" needs further explanation.

Also the GPG situation I've discussed isn't about sandboxing. (In my previous comment, by "sandboxing VS Code" I meant running the entire graphical application in a VM.) The Remote extensions are doing what they were intended to do. If some desktop VM software "helpfully" mapped the local machine's entire home directory into a VM without telling the user, we wouldn't say that's a sandboxing failure.

VS Code does something similar with injecting git credentials, as was discussed in #5500 from @markomitranic and in other issues for over two years. Maybe it's not worth using this GPG situation as an example any more without more information about why the equivalent git options remain undocumented.

[jeremyn]

@alexdima In #6391 @Tyriar wrote "Microsoft/our team encourages the use of containers which enhance security and ease of setup." You wrote, above, "you should not use dev containers as a sandbox". In #6391 (comment) @Tyriar suggests these statements don't conflict, but I'm confused. Could you please explain?

[Tyriar]

@jeremyn i said they enhance security, not provide "absolute security".

[jeremyn]

@Tyriar Well yeah, very little provides absolute security. Even classic examples of security theater technically enhance security in some minor way.

To be clear I'm not trying to play word games or gotchas. The key issue is whether Microsoft recommends using containers to provide isolation or not. @alexdima says they don't, you say they do.

Recall the inspiration here is VS Code Remote-* injecting sensitive info such as the GPG public key database into a container by default and without telling the user. If desktop VM software (VMware, VirtualBox) did this it would be completely ridiculous, not just a bug but a catastrophic design flaw. This is because these products are intended to provide airtight seals between the VM and host (and other VMs) and quietly copying sensitive data into a VM violates the very intention of these products.

So the question is what is the intention, or assumption, behind the VS Code Remote-* extensions:

• If as @alexdima wrote the VS Code devs assume the local and remote environments have equal trust, then this copying of sensitive data makes sense, and there is no way to defend against it other than putting VS Code itself in a sandbox such as a graphical VM. Even if a user restricts copying for git/GPG/SSH, the VS Code team might add some other injection later on.

• On the other hand if as @Tyriar wrote, Microsoft recommends using containers as a security measure (presumably with VS Code Remote-*), then this copying of sensitive data deserves much more scrutiny, and once resolved users can be confident that no other injections will be added, or if they are it will be with ample notice and ways to avoid it.

Currently it seems there's a dangerous situation where maybe one team is writing code as if there is no local/remote trust boundary, and another team is recommending remote environments because they assume a local/remote trust boundary provides security. The fact that a local/remote trust boundary enhances security in (only) some ways is not so important, because malicious authors can trivially target their malware at the exposed areas. So this tension should be resolved somehow, either internally in the VS Code team, or by clarifying here if there is just some mixed messaging.