Hacker News Reader

Comment by ajsharp | Hacker News Reader

This is the relevant part:

> The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:

- Wander around the filesystem - Edit arbitrary files - Launch its own shell PTY processes - Persist itself

When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client. At a minimum, the client would have to explicitly take action for that to happen.

View on HN

Is that to say that the server can do things on the client connecting to the server? That doesn't make much sense.

That's what makes this blog post worthy

"For VS Code remote, the VS Code server is in the same trust boundary as the VS Code client. [...]

For Remote SSH: [...] A compromised remote could use the VS Code Remote connection to execute code on your local machine."

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

I wrote about it in a bit more detail a month ago because it seems to be a common misunderstanding: "VS Code Remote Dev and Dev Containers are not security boundaries" https://lets.re/blog/vscode-remote-dev/

So this is why VSCode somewhat recently started asking if I trusted the authors/owners of remote folders.

That is why I exclusively run vscode in a virtual machine and use it through a browser tab on the host machine.

Luckily the web version is indistinguishable from the "native" version, they did a great work there.

Just share a folder with the VM and then bind mount whatever you want to edit at the time. No need to trust the author with all your credentials.

Editing files on a server resulting in remote code execution apparently by design is such a classic 2004-Microsoft thing to do.

I see. I was intending to use a container to sandbox npm/yarn, it sounds like that is pointless.

npm scares me - if there is a way to sandbox it on a mac, I'd like to know.

Containers on MacOS are ran inside a Linux VM. If you ensure that the Linux VM doesn't have access to anything besides the required files/networks, that should be pretty secure.

Best case you go through the settings of Docker, Podman or whatever you use to limit integrations. Then, from within the VM and container see what networks, files, etc. you can reach to be sure.

I think in context the challenge here is to use remote editing to treat the container as a VSCode remote. As shown, that's not enough of a sandbox because the agent gives a route out.

macOS has a formal sandboxing language; I first learned about it via iTerm2's build process: https://gitlab.com/gnachman/iterm2/-/blob/v3.5.12beta2/deps.... consumed by /usr/bin/sandbox-exec https://gitlab.com/gnachman/iterm2/-/blob/v3.5.12beta2/Makef...

I haven't tried to use it in anger, but I believe this is the likely starting point https://developer.apple.com/documentation/xcode/configuring-...

I've attempted to use the sandbox-exec utility, but didn't have the stamina to get a working sandbox file written.

In general, I'd like to be able to sandbox more things. I'm using the app store version of slack because slack doesn't really need access to all of my files.

deno has been somewhat pleasing in this space, it's not a perfect boundary though

> When you ssh into a remote server as a client, afaik that server cannot execute arbitrary code on the client.

...assuming you have X11 forwarding disabled and/or don't have X11 server running on the same system that your client is running on.

I'm pretty sure X11 forwarding is opt-in, not opt-out? That is, if you don't run `ssh -X` or -Y then this isn't a problem

Usually it should also not be problem with -X because then the client is not trusted (but some distributions change the defaults here because some clients then don't work properly! unfortunately, there is not much interest in fixing this since two decades because X is dead anyway or so)

I've never seen any distributions enable ForwardX11Trusted by default. Do you have any examples? It seems very unlikely to me that a distribution would do this for a relatively niche use case.

Debian does this.

If I have X11 forwarding on, what can Evil apps do? Launch UI for sure. Screenshots? I imagine so. What else? Send keyboard events, which would be game over?

They can only do those things if the X11 security extension restrictions are disabled with ForwardX11Trusted=yes or by using -Y rather than -X. This has been the case for the past 20 years.

Also read keyboard events / do keylogging

Reply on news.ycombinator.com