Hacker News Reader

Comment by shipp02 | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

Can you give a specific example of exploitation of a theoretical bug in the agent?

They wrote "compromised" not "buggy". There does not have to be any bug. It can all work as intended... by an attacker!

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.

A user that can manage remote processes is generally going to have pretty high permissions.

For example, opening up debug ports on the running server processes, sudo privileges, or just the ability to run arbitrary code or curl in random binaries from the internet.

We usually don't hand over full ssh sessions to third party programs, so while you're right, I think people are not used to this level of trust into an app.

The article was to me a good reminder that it's a whole other level of access than just remote mounting a file system.

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

Sounds like, if you take this to the limit, the course of action is to not touch a computer?

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.

From a security perspective, the very best option is to prevent anyone else from touching it either. Including to turn it on.

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.

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.

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.

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

I think you are talking about 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.

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.

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

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

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.

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

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.

I have never seen a compelling explanation for why curl | bash is a security problem.

It's possible to detect "curl | bash" server side. See https://news.ycombinator.com/item?id=34145799

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 :)

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.

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.

It is not a security problem if you know what you are doing and trusting the source. As a general way of installing software is is problematic because it is a risk when careless users execute untrusted code from the internet. Using this in cases where it could be seen a safe encourages such unsafe behavior and undermines efforts to train users not to do this. There is also the issue that websites are generally less safe than dedicated infrastructure of distributions. Those also typically ensure some level of quality control and auditing.

If I want to run a software written by someone, going to that someone's site and grabbing the source and/or binary straight from them seems like a pretty straight-forward decision, you don't need some middle man of a "distribution maintainer".

Besides, while I appreciate the efforts of the distro package maintainers, they are overworked and can't really give the amount of care this huge pile of software in the repository needs, not to mention that sometimes their efforts are counterproductive (IIRC Debian used to deliberately break some terminfo(5) records to work around problems in some other packages). And I definitely remember reading an article (though I can't for the love of me to find it) about a Linux distro doing an automated switch from some sort of RPM-like packaging to straight-up using Flatpak, with predictably horrible results of lots and lots of broken software.

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.

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

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.

VSCode is opensource. Remote ssh agent is not.

What's that got to do with anything?

that you can theoritically audit vscode code, but not ssh agent code...

Does that have anything to do with SECURITY?

The train of logic has run way off the rail in this thread.

VSCode is not if installed with binaries.

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.

No -- when I ssh somewhere I am NOT giving them (the server) permission to run code on MY computer. When I vscode-remote somewhere then I AM giving them (the server) to run code on MY computer. You don't expect visiting a website to give the website permission to edit your local files, and so similarly some people might expect that if they are remote-editing with vscode they are not giving the remote-server permission to edit their local files either. Best to be aware!

How does it differ from just logging into that machine and running code?

VSCode remotes can execute code on the connecting clients, so a pwned remote server can pwn your local machine.

I mean, yeah, technically true - although you would connect in untrusted mode if you didn't trust the machine where you were editing code. At that point it should only be slightly more dangerous than opening a web page from the remote server.

So yeah, if you don't trust the remote machine then I agree - you probably shouldn't use it. But I don't really think that's the use-case they had in mind.

In that it's like THAT machine is also logging into your machine, and running code there...

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.

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

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.

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.

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?

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.

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

Not surprising considering that fly.io is an unreliable mess.

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

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

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.

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.

Reply on news.ycombinator.com