← Back to context

Comment by 10000truths

16 hours ago

So a program that is specifically designed to edit files and run arbitrary commands on a remote machine... can do so. Not sure where the bananas part comes in. Sending a binary over SSH/SFTP might sound weird at first glance, but VSCode can't assume that your remote machine can access the wider internet, and it needs a reliable way to bootstrap the agent on the remote. Shipping it over the SSH tunnel is the natural solution.

TRAMP (mentioned in the article) does it without installing anything on remote machine, just SSH, and shell commands. Which sounds more natural to me. Node.js security history, with all due respect, is not shiny. And the problem the author has with VSCode's way, I guess, is not that it can edit files, but that it extends attack surface without real need.

  • TRAMP actions are also rather slow (high latency). OTOH, tramp-rpc relies on a little tool to run on the remote and is much snappier. This proves there is a better middle ground than TRAMP with nothing and whatever abomination VSCode injects. Basically, busybox with a persistent RPC connection is all one needs.

I think the actual concern, not well expressed in the blog post, is the fact that node and vscode server are installed on, for instance, a prod machine that (probably) should be very tightly controlled in terms of what software is installed and running. You don't want to unwittingly add to the attack surface

  • This should be covered by not giving developers SSH shell or equivalent access to production machines in the first place, or at the very least to have measures in place (ACLs, quotas, etc.) to strictly limit what they are able to do from the shell.

  • Fair enough, but running VSCode on a prod machine is also bananas.

    • Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.

      1 reply →

    • agree, but do you think every dev you know konws this?

      also "i just want to edit a config file and i want a nice ui", is how you get there.

      3 replies →

  • Pre-Download a known good VSCode server binary. VSCode will detect and use it.

    What more could you ask for?

Am I that much of? My reading of the following was that the remotely executed agent pushes commands back to your local vscode.

> [...] VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node. [...]

> It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:

Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

The issue is that the model can be the attacker, and use the link back to your host.

  • This really seems bananas. Why? What is the legitimate use case of the remote agent being able to run code on the local client's machine!?

The bananas part is that it dumps 500 MB of stuff on the remote side.

  • Yeah, I learned how it worked when I made the mistake of trying to use it to develop on a Raspberry Pi, where it filled the disk and crashed/hung the Pi by using all the RAM until it started using swap. Fell back to local with an sshfs mount instead.

  • I just removed 5.5Gb of stale ~/.vscode-server from a dev VM

    • Oh wow I just checked my servers and on one the folder is 3.2GB and another has 1.7GB. It kind of looks like it just keeps copies of every version its ever installed? Theres several copies of node and `node_modules` folders.

      I'm not super low on space but it also pretty clearly doesn't need to be that large, it looks like most of it is copies of itself.