[shitter]

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

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]

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

[w0m]

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.

[zelphirkalt]

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

[makeitdouble]

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.

[cogman10]

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.