7 ms·

This is going to sound naive but, I don't understand what the security issue is. If you can ssh into a machine and port forward a socket, you already have permi

This is going to sound naive but, I don't understand what the security issue is. If you can ssh into a machine and port forward a socket, you already have permission to do all the other things. VSCode's protocol seems to be exposing it in way that's more convenient for them. How is this a security problem? Is it because someone on the same network as the remote machine but without SSH access can connect the port that is forwarded over SSH? As a user, I quite like how well VSCode's SSH system works.

schmichael 2y ago
I think the difference is that what VSCode is doing is not an SSH Session like you get in a terminal with the ssh command or putty. VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user. Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.
- shipp02 2y ago
  Is it better to programmatically interact with bash to provide the features VSCode does? Do note that I am unwilling to accept an implementation with less features/ease of use! I can see how writing a custom agent that provides remote access to privileged API's is a bad idea but bash isn't exactly the most secure piece of software in the world.
  - zelphirkalt 2y ago
    Bash is not running though. You might get a Bash session once you connect via SSH, but it just sits there waiting for you to input commands, while the VS Code installed agent thing does network stuff on its own iiuc. Bash is not acting as a server, afaik.
- shitter 2y ago
  > However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh. I can see how this increases local (to the remote system) attack surface, but as long as the agent has the same OS privileges as the user logged in over SSH, what extra remote risk does this introduce?
  - smackeyacky 2y ago
    Because if the Agent code is compromised, the fact that it leaves things behind is enough for an attacker to hide whatever they need along with the vs code blob. Vscode does this for the right reason, mostly it’s so the bulk of it runs on the host where you’re doing remote development or WSL or whatever. But like a lot of dev stuff these days, compromise the npm packages and bingo you can own all the machines. Npm is already a terrible thing because the packages are managed so haphazardly, but now you’re exposed to the nonsense without even going anywhere near the mad rodeo of node. I like vscode but it’s not going anywhere near a machine I care about.
    - lostmsu 2y ago
      Can you give a specific example of exploitation of a theoretical bug in the agent?
      - zelphirkalt 2y ago
        They wrote "compromised" not "buggy". There does not have to be any bug. It can all work as intended... by an attacker!
      - w0m 2y ago
        The argument is that you're running code on the remote host, and it could be compromised. The same argument can be made about any code you run on the remote. VSCode may be seen as a larger attack vector due to its popularity; but maybe not as many won't use the SSH agent? It's also fairly common sense that you should never run it to mount on a production resource; but again, you shouldn't be able to ssh into a production machine anyway.
- TZubiri 2y ago
  I sometimes kick myself for not being more productive. But then I see the clusterfucks productive people are doing and it looks like I'm onto something
  - eru 2y ago
    Sounds like, if you take this to the limit, the course of action is to not touch a computer?
    - what-the-grump 2y ago
      Just like if you take eating healthy to the limit, the course of action is to not eat and starve to death? That’s why we don’t take things to the limit right? That’s how you get a singularity.
    - regularfry 2y ago
      From a security perspective, the very best option is to prevent anyone else from touching it either. Including to turn it on.
- wg0 2y ago
  Anyone doing such remote edits on production or even staging systems is past the point of caring about any security implications. The remote development workflow is intended and should be used for dedicated disposable development machines. That's the responsibility of the operator and it is not for the tool to take care of.
- 3abiton 2y ago
  This is really big. I always thought Vscode ssh capability was just some black magic that the open source community wasn't able to replicat well with vscodium extensions. Yet, it seems the reason why is that MS threw a curve ball with that naming.
- 0xbs0d 2y ago
  I think the latest Jetbrains tools do the same or similar things. They also install their own server on the target machine and connect to that. And I mean it's Jetbrains, so again, closed source tools. But it's not Microsoft so nobody is talking about it I guess.
  - rtsil 2y ago
    If you're thinking about JetBrains' remote development, it's actually the IDE (a headless version) that's installed on the remote dev machine. Since you first need to install the IDE on the dev server first, you are never under any illusion that it's a simple SSH-based remote editing à la vim (even though it also relies on SSH).
  - Y-bar 2y ago
    I think you are talking about https://www.jetbrains.com/remote-development/gateway/ https://www.jetbrains.com/remote-development/gateway/ which requires a separate manual install on the client followed by a manual installation on the server during setup. It is not part of the regular IntelliJ IDE as far as I can see.
    - 0xbs0d 2y ago
      It isn’t. I mean yeah gateway is what you described. But the functionality is also included in Jetbrains IDEs and doesn’t require any manual install on the server. It installs its own thing exactly like VSCode does.
      - Y-bar 2y ago
        I can't find any such thing in PhpStorm v2024.3, can you tell me the feature name? Is it this you are thinking of (which requires some clear manual steps)? https://www.jetbrains.com/help/phpstorm/remote-development-overview.html#use_local_ide https://www.jetbrains.com/help/phpstorm/remote-development-o...
  - _boffin_ 2y ago
    They have two ways — remote development, which is what you’re saying and remote execution. Remote execution is the one I prefer. Rsync and then just runconfig. It’s lightweight and simple
indigodaddy 2y ago
he says in the article, that the agent seems to be just fucking about at will
- __MatrixMan__ 2y ago
  ...which I've come to expect from Microsoft. Windows scrozzles the efi partition for my other OS every third or fourth time it installs updates. It's like they think they own every computer they have code on.
  - smolder 2y ago
    They do think they own every computer they have code on. This is modern computing. Your hardware is an extension of "the cloud", if you let MS, apple, or any other big co into it.
    - deleted 2y ago
      [deleted]
- ydj 2y ago
  But the author doesn’t give a single example, and so there’s nothing someone else can do to explain why or continue the conversation. The best we got use that he has a vague sense of unease, which I don’t think is very useful.
deleted 2y ago
[deleted]
ajsharp 2y ago
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.
Deathmax 2y ago
It's helpful for evading detection, because if you've compromised a machine, you can drop in the server binary and it'll have been added to the allowlist for devs to run.
rkagerer 2y ago
One reason it's a problem is because it's very unexpected behavior. Software should follow some sort of pattern that you can develop a reasonable mental model around.
fulafel 2y ago
> If you can ssh into a machine and port forward a socket, you already have permission to do all the other things. Only technically. There are lots of situations where people (or robotic alarm bells) will be miffed if you instal your custom sw stacks, remote shells, "i don't know what these binaries are" etc on some servers you're supposedly just editing config files on.
- spudlyo 2y ago
  There are lots of situations where people will not notice at all. At my last gig, I wrote pretty extensive Ansible manifests that built and configured all my favorite tools on on bog-standard company provided development hosts so I found them cozy for remote work. I took severe liberties with these hosts and nobody batted an eye.
  - fulafel 2y ago
    Yeah, this is just being sensible. There at most you might lack some approval for your solid engineering decision. But when the described kind of worming in happens without your knowledge and there's just some random reverse shell stuff appearing out of nowhere, nobody has looked the sw through it to see if it's secure, what's the supply chain, etc, it's different.
slashdave 2y ago
> you already have permission to do all the other things Of course. The problem is that a 3rd party agent can now use your permission to do what it wants, and you will be none the wiser.
- IshKebab 2y ago
  You're already trusting that third party agent on your own computer. If VSCode itself was malware then it can do anything you can do, including sshing into remote machines and running commands behind your back.
  - bornfreddy 2y ago
    VSCode is opensource. Remote ssh agent is not.
    - IshKebab 2y ago
      What's that got to do with anything?
      - coldtea 2y ago
        that you can theoritically audit vscode code, but not ssh agent code...
    - n144q 2y ago
      Does that have anything to do with SECURITY? The train of logic has run way off the rail in this thread.
    - Nab443 2y ago
      VSCode is not if installed with binaries.
      - bornfreddy 2y ago
        Are you saying that the VSCode binaries are not built from the exact source that is available? Or that the opensource license doesn't apply to the version of VSC that is distributed via binaries? I'm using VSCodium myself anyway, but I'm also installing it from binaries (precompiled packages), as is the case with most opensource software I use.
gorgoiler 2y ago
The agent on the dev server is now a vector back to VS Code on your laptop. The agent is networked and running all the time so a hole on the dev server’s firewall is now a hole in your laptop’s firewall.
IshKebab 2y ago
There is no security issue. The author seems a bit confused.
- dangus 2y ago
  Not surprising considering that fly.io is an unreliable mess.
jcgl 2y ago
I think you’re basically right: it’s not a security problem in that it doesn’t inherently traverse any vulnerabilities or security boundaries. But it is a security problem in the same way that “curl | bash” is a security problem. An even closer equivalence might be something like “curl | bash” in your bashrc.
- School-Cotton 2y ago
  I have never seen a compelling explanation for why curl | bash is a security problem.
  - 1una 2y ago
    It's possible to detect "curl | bash" server side. See https://news.ycombinator.com/item?id=34145799 https://news.ycombinator.com/item?id=34145799
    - awwaiid 2y ago
      Detect AND change what is sent from the server. So you open the link in a browser and see that the remote shell code is fine, does what you want, then you `curl | bash` it and it sends a completely different program to run. If you trust where you are curling from, and you trust everyone they trust and that they definitely haven't been hacked, then great! Blindly eval that code! That's what I do :)
    - Dylan16807 2y ago
      The threat model where a malicious server can trick curl|bash but not the alternatives is extremely narrow. Reacting to curl|bash is missing the forest for the single tree.
  - jcgl 2y ago
    In my mind, it mostly is about curl|bash not being auditable. On the spectrum of [auditable to not-auditable], curl|bash is as far to the right as possible, with things like distro packages far to the left. Maybe for a specific piece of software that's okay, but I think we would readily agree that it'd be a problem for all components of an OS to use bash|curl. Bear in mind that, like many bits of security advice, this is highly context-dependent. It may vary based on your risk tolerance, your level of trust in the vendor, how robust other parts of your infrastructure (e.g. threat monitoring tools, network segmentation, etc.) are.
cryptonector 2y ago
A piece of software that is ostensibly trying to help you is gathering information without your knowledge and.. one of these days may upload it to the mothership? That's kinda not ok don't you think?

schmichael 2y ago

I think the difference is that what VSCode is doing is not an SSH Session like you get in a terminal with the ssh command or putty. VSCode is installing a remote agent on the target machine that happens to use ssh as its transport protocol, and offers to share that transport with the user. Is this a problem? Not if it only does things you want it to do. However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh.

shipp02 2y ago
Is it better to programmatically interact with bash to provide the features VSCode does? Do note that I am unwilling to accept an implementation with less features/ease of use! I can see how writing a custom agent that provides remote access to privileged API's is a bad idea but bash isn't exactly the most secure piece of software in the world.
- zelphirkalt 2y ago
  Bash is not running though. You might get a Bash session once you connect via SSH, but it just sits there waiting for you to input commands, while the VS Code installed agent thing does network stuff on its own iiuc. Bash is not acting as a server, afaik.
shitter 2y ago
> However any agent based system exposing an arbitrary API is suddenly a much bigger attack and risk surface area than the well trod (and still fraught) path of emulating a terminal over ssh. I can see how this increases local (to the remote system) attack surface, but as long as the agent has the same OS privileges as the user logged in over SSH, what extra remote risk does this introduce?
- smackeyacky 2y ago
  Because if the Agent code is compromised, the fact that it leaves things behind is enough for an attacker to hide whatever they need along with the vs code blob. Vscode does this for the right reason, mostly it’s so the bulk of it runs on the host where you’re doing remote development or WSL or whatever. But like a lot of dev stuff these days, compromise the npm packages and bingo you can own all the machines. Npm is already a terrible thing because the packages are managed so haphazardly, but now you’re exposed to the nonsense without even going anywhere near the mad rodeo of node. I like vscode but it’s not going anywhere near a machine I care about.
  - lostmsu 2y ago
    Can you give a specific example of exploitation of a theoretical bug in the agent?
    - zelphirkalt 2y ago
      They wrote "compromised" not "buggy". There does not have to be any bug. It can all work as intended... by an attacker!
    - w0m 2y ago
      The argument is that you're running code on the remote host, and it could be compromised. The same argument can be made about any code you run on the remote. VSCode may be seen as a larger attack vector due to its popularity; but maybe not as many won't use the SSH agent? It's also fairly common sense that you should never run it to mount on a production resource; but again, you shouldn't be able to ssh into a production machine anyway.
TZubiri 2y ago
I sometimes kick myself for not being more productive. But then I see the clusterfucks productive people are doing and it looks like I'm onto something
- eru 2y ago
  Sounds like, if you take this to the limit, the course of action is to not touch a computer?
  - what-the-grump 2y ago
    Just like if you take eating healthy to the limit, the course of action is to not eat and starve to death? That’s why we don’t take things to the limit right? That’s how you get a singularity.
  - regularfry 2y ago
    From a security perspective, the very best option is to prevent anyone else from touching it either. Including to turn it on.
wg0 2y ago
Anyone doing such remote edits on production or even staging systems is past the point of caring about any security implications. The remote development workflow is intended and should be used for dedicated disposable development machines. That's the responsibility of the operator and it is not for the tool to take care of.
3abiton 2y ago
This is really big. I always thought Vscode ssh capability was just some black magic that the open source community wasn't able to replicat well with vscodium extensions. Yet, it seems the reason why is that MS threw a curve ball with that naming.
0xbs0d 2y ago
I think the latest Jetbrains tools do the same or similar things. They also install their own server on the target machine and connect to that. And I mean it's Jetbrains, so again, closed source tools. But it's not Microsoft so nobody is talking about it I guess.
- rtsil 2y ago
  If you're thinking about JetBrains' remote development, it's actually the IDE (a headless version) that's installed on the remote dev machine. Since you first need to install the IDE on the dev server first, you are never under any illusion that it's a simple SSH-based remote editing à la vim (even though it also relies on SSH).
- Y-bar 2y ago
  I think you are talking about https://www.jetbrains.com/remote-development/gateway/ https://www.jetbrains.com/remote-development/gateway/ which requires a separate manual install on the client followed by a manual installation on the server during setup. It is not part of the regular IntelliJ IDE as far as I can see.
  - 0xbs0d 2y ago
    It isn’t. I mean yeah gateway is what you described. But the functionality is also included in Jetbrains IDEs and doesn’t require any manual install on the server. It installs its own thing exactly like VSCode does.
    - Y-bar 2y ago
      I can't find any such thing in PhpStorm v2024.3, can you tell me the feature name? Is it this you are thinking of (which requires some clear manual steps)? https://www.jetbrains.com/help/phpstorm/remote-development-overview.html#use_local_ide https://www.jetbrains.com/help/phpstorm/remote-development-o...
- _boffin_ 2y ago
  They have two ways — remote development, which is what you’re saying and remote execution. Remote execution is the one I prefer. Rsync and then just runconfig. It’s lightweight and simple

indigodaddy 2y ago

he says in the article, that the agent seems to be just fucking about at will

__MatrixMan__ 2y ago
...which I've come to expect from Microsoft. Windows scrozzles the efi partition for my other OS every third or fourth time it installs updates. It's like they think they own every computer they have code on.
- smolder 2y ago
  They do think they own every computer they have code on. This is modern computing. Your hardware is an extension of "the cloud", if you let MS, apple, or any other big co into it.
  - deleted 2y ago
    [deleted]
ydj 2y ago
But the author doesn’t give a single example, and so there’s nothing someone else can do to explain why or continue the conversation. The best we got use that he has a vague sense of unease, which I don’t think is very useful.

deleted 2y ago

[deleted]

ajsharp 2y ago

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.

Deathmax 2y ago

It's helpful for evading detection, because if you've compromised a machine, you can drop in the server binary and it'll have been added to the allowlist for devs to run.

rkagerer 2y ago

One reason it's a problem is because it's very unexpected behavior. Software should follow some sort of pattern that you can develop a reasonable mental model around.

fulafel 2y ago

> If you can ssh into a machine and port forward a socket, you already have permission to do all the other things. Only technically. There are lots of situations where people (or robotic alarm bells) will be miffed if you instal your custom sw stacks, remote shells, "i don't know what these binaries are" etc on some servers you're supposedly just editing config files on.

spudlyo 2y ago
There are lots of situations where people will not notice at all. At my last gig, I wrote pretty extensive Ansible manifests that built and configured all my favorite tools on on bog-standard company provided development hosts so I found them cozy for remote work. I took severe liberties with these hosts and nobody batted an eye.
- fulafel 2y ago
  Yeah, this is just being sensible. There at most you might lack some approval for your solid engineering decision. But when the described kind of worming in happens without your knowledge and there's just some random reverse shell stuff appearing out of nowhere, nobody has looked the sw through it to see if it's secure, what's the supply chain, etc, it's different.

slashdave 2y ago

> you already have permission to do all the other things Of course. The problem is that a 3rd party agent can now use your permission to do what it wants, and you will be none the wiser.

IshKebab 2y ago
You're already trusting that third party agent on your own computer. If VSCode itself was malware then it can do anything you can do, including sshing into remote machines and running commands behind your back.
- bornfreddy 2y ago
  VSCode is opensource. Remote ssh agent is not.
  - IshKebab 2y ago
    What's that got to do with anything?
    - coldtea 2y ago
      that you can theoritically audit vscode code, but not ssh agent code...
  - n144q 2y ago
    Does that have anything to do with SECURITY? The train of logic has run way off the rail in this thread.
  - Nab443 2y ago
    VSCode is not if installed with binaries.
    - bornfreddy 2y ago
      Are you saying that the VSCode binaries are not built from the exact source that is available? Or that the opensource license doesn't apply to the version of VSC that is distributed via binaries? I'm using VSCodium myself anyway, but I'm also installing it from binaries (precompiled packages), as is the case with most opensource software I use.

gorgoiler 2y ago

The agent on the dev server is now a vector back to VS Code on your laptop. The agent is networked and running all the time so a hole on the dev server’s firewall is now a hole in your laptop’s firewall.

IshKebab 2y ago

There is no security issue. The author seems a bit confused.

dangus 2y ago
Not surprising considering that fly.io is an unreliable mess.

jcgl 2y ago

I think you’re basically right: it’s not a security problem in that it doesn’t inherently traverse any vulnerabilities or security boundaries. But it is a security problem in the same way that “curl | bash” is a security problem. An even closer equivalence might be something like “curl | bash” in your bashrc.

School-Cotton 2y ago
I have never seen a compelling explanation for why curl | bash is a security problem.
- 1una 2y ago
  It's possible to detect "curl | bash" server side. See https://news.ycombinator.com/item?id=34145799 https://news.ycombinator.com/item?id=34145799
  - awwaiid 2y ago
    Detect AND change what is sent from the server. So you open the link in a browser and see that the remote shell code is fine, does what you want, then you `curl | bash` it and it sends a completely different program to run. If you trust where you are curling from, and you trust everyone they trust and that they definitely haven't been hacked, then great! Blindly eval that code! That's what I do :)
  - Dylan16807 2y ago
    The threat model where a malicious server can trick curl|bash but not the alternatives is extremely narrow. Reacting to curl|bash is missing the forest for the single tree.
- jcgl 2y ago
  In my mind, it mostly is about curl|bash not being auditable. On the spectrum of [auditable to not-auditable], curl|bash is as far to the right as possible, with things like distro packages far to the left. Maybe for a specific piece of software that's okay, but I think we would readily agree that it'd be a problem for all components of an OS to use bash|curl. Bear in mind that, like many bits of security advice, this is highly context-dependent. It may vary based on your risk tolerance, your level of trust in the vendor, how robust other parts of your infrastructure (e.g. threat monitoring tools, network segmentation, etc.) are.

cryptonector 2y ago

A piece of software that is ostensibly trying to help you is gathering information without your knowledge and.. one of these days may upload it to the mothership? That's kinda not ok don't you think?