Comment by amluto
4 hours ago
The security measure that the developer didn't use was completely refusing to use vscode.
vscode has no security model. It's not like swiss cheese where there are holes and some of the go all the way through. vscode is all hole with some cheese on the side. There is absolutely no isolation between the front-end process, the backend size (the thing that runs in the remote or the devcontainer), and any extensions or anything that might be in a repository whose authors you "trust".
Or you can just refuse to use random extensions. I built my own extensions if I needed them. You're a programmer, right? The whole point of extensibility is that you, or your company, can program what you need from your IDE, without having to make a whole IDE from scratch. I have since moved on to making my own IDE, mostly because I hate Electron and its >1gb memory footprint, but vscode served me so much better than anything else for years, without installing a single rando's extension.
Kind of.
A vscode workspace can trivially execute code on the machine that runs the server end of vscode. (This is how building works -- there is no sandbox unless the workspace config explicitly uses some kind of sandbox.) So the workspace can usually trivially elevate permissions to take over the vscode server, including installing extensions on it without asking you.
In principle, there is a teeny tiny bit of isolation between the local and remote sides, so the remote side cannot trivially execute code on the local machine. But I recommend reading this rather long-standing ticket:
https://github.com/microsoft/vscode-remote-release/issues/66...
It would be nice if there was an easy way to prevent people from installing vscode remotes on a shared server... Probably can run an ebpf routine to disallow creation of folders named . vscode*
1 reply →
> You're a programmer, right?
This is my position as well, but it's rarely received well. Usually, a response like "why would I rewrite something that's already been written and available?" By writing the code, I know how it works. I know it is not infected with crap. I know it will not in the future be infected with crap from a down stream dependency. It seems to me this really took off with node to the point that it's laughable at what people will include with no thought at all. I know component libraries have existed for many other languages before, but node just stands out to me
Most bosses look poorly upon spending their budget on rewriting software that already exists and simultaneously most bosses(although not the exact same set) don’t care about security until a disaster has already occurred.
And it’s also not like you’re going to literally write every piece of software you use, unless you’ve started all the way down at machine code you’re drawing the line somewhere on using code written by other people.
> I built my own extensions if I needed them. You're a programmer, right? The whole point of extensibility is that you, or your company, can program what you need from your IDE,
Dude, get real. We don't all have the luxury of being able to engage in endless IDE extension programming side quests just to do our day jobs. And even if we did, there's the reality that whatever you produce is probably not nearly as feature complete or bug free as the extension someone spent years writing. Hence why people want to reach for off the shelf solutions.
> just to do our day jobs.
Ah, there it is. The root of most problems in the software industry: people who hate programming and avoid doing it as much as possible, because they only got into it for the money.
I have no problem writing extensions in my spare time because programming is fun. Because I know how to program, like, actually program and not just copypaste stuff off StackOverflow, it doesn't take years to write a vscode extension, either.
2 replies →