6 ms·

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 underlyi

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.

khana 2y ago
[dead]
KTibow 2y ago
Is that to say that the server can do things on the client connecting to the server? That doesn't make much sense.
- Maxious 2y ago
  That's what makes this blog post worthy
- retsl 2y ago
  "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/6608#issuecomment-1112960548 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/ https://lets.re/blog/vscode-remote-dev/
  - mbreese 2y ago
    So this is why VSCode somewhat recently started asking if I trusted the authors/owners of remote folders.
    - kobalsky 2y ago
      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.
  - formerly_proven 2y ago
    Editing files on a server resulting in remote code execution apparently by design is such a classic 2004-Microsoft thing to do.
  - dunham 2y ago
    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.
    - retsl 2y ago
      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.
      - regularfry 2y ago
        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.
    - mdaniel 2y ago
      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.sb 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/Makefile#L174 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-the-macos-app-sandbox https://developer.apple.com/documentation/xcode/configuring-...
      - dunham 2y ago
        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.
inetknght 2y ago
> 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.
- yjftsjthsd-h 2y ago
  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
  - uecker 2y ago
    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)
    - donio 2y ago
      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.
      - uecker 2y ago
        Debian does this.
- awwaiid 2y ago
  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?
  - donio 2y ago
    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.
deleted 2y ago
[deleted]

khana 2y ago

[dead]

KTibow 2y ago

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

Maxious 2y ago
That's what makes this blog post worthy
retsl 2y ago
"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/6608#issuecomment-1112960548 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/ https://lets.re/blog/vscode-remote-dev/
- mbreese 2y ago
  So this is why VSCode somewhat recently started asking if I trusted the authors/owners of remote folders.
  - kobalsky 2y ago
    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.
- formerly_proven 2y ago
  Editing files on a server resulting in remote code execution apparently by design is such a classic 2004-Microsoft thing to do.
- dunham 2y ago
  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.
  - retsl 2y ago
    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.
    - regularfry 2y ago
      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.
  - mdaniel 2y ago
    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.sb 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/Makefile#L174 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-the-macos-app-sandbox https://developer.apple.com/documentation/xcode/configuring-...
    - dunham 2y ago
      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.

inetknght 2y ago

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

yjftsjthsd-h 2y ago
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
- uecker 2y ago
  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)
  - donio 2y ago
    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.
    - uecker 2y ago
      Debian does this.
awwaiid 2y ago
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?
- donio 2y ago
  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.

deleted 2y ago

[deleted]