241–250 of 488 posts
Earlier quoted context omitted.
friendly reminder: use vim :)
If you are a person that installs extensions from public sources, it doesn't matter what IDE you use. If you don't (or can't) install extensions, it also doesn't matter which IDE you use.
friendly reminder: - disable auto-updates for extensions in VS Code/Cursor - use static analysis for GitHub Actions to catch security issues in pre-commit hook and on ci: https://github.com/zizmorcore/zizmor - set locally: pnpm config set minimum-release-age 4320 # 3 days in minutes https://pnpm.io/supply-chain-security - for other package managers check: https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e..…
> for other package managers
For other js package managers. Sadly such functionality seems far less common for c# (nuget) or rust (cargo).
> add Socket Free Firewall when installing npm packages on CI to catch malware
It appears that functionality depends on blacklisting malware from being downloaded? But don't the repositories (npm, etc) take down malware once it's identified - is socket actually blacklisting malware faster than npm? That sounds unlikely, but maybe? For the vs code extension from the op post, it seems like it was live for like 18 minutes on the official vs code marketplace, and slightly longer on openvsx as ms sadly doesn't allow vs code clones to use the official marketplace.
Earlier quoted context omitted.
What are you withholding from the sandbox without making it useless?
Internet access. An editor extension does not need it.
One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.
Earlier quoted context omitted.
its easy to complain, words are cheap. fork it and change it if you don't like it
It's easy to wave a magic wand and have one developer do better than a corporation of tens of thousands. There is a reason I don't use Microsoft products: I can't do it myself and do won't do it for me.
Emacs, vim/nvim, intellij, etc… pretty much all vulnerable to such an attack
Reality is most devs wouldn’t be satisfied with the limitations proper sandboxing would create.
Vs code extensions have been terrifying for a long time. Such a wild and obvious attack vector. I'm constantly getting pop ups in vscode to install an extension because it recognizes a certain file type. It's 50-50 whether that extension is owned by a company or some random dev. Some of these have millions of installs and on first glance appear to be official company owned extensions. I'm at a point in my life where…
The problem extends far beyond VS code. All extensions and executable code has the same problem. There was a case where Disney was hacked because an employee installed a BeamNG mod that had bundled malware. A company that wants to remain secure would have to employ strict restrictions on installing software. Only installing npm packages and plugins from an internal preapproved repo for example.
Maybe I'm missing something really obvious, but... 3,800 repos? I guess I find it kind of surprising they have that many!
Is there any way to know if my repos were affected?
Earlier quoted context omitted.
I don’t understand why we don’t just sandbox everything. We have done it for web browsers, we can definitely do it for VSCode extensions.
Because it's hard to create a system that is both sandboxed and powerful. You can't have an extension system that allows a plugin to run a locally installed linter or view the status of docker containers but can't execute something malicious. I do agree though that it is incredibly important to start taking sandboxing seriously. But there is a lot of difficulty and friction, and most of the users will scream and cry…
Yes you can. Extension systems of today have multiple problems that prevent that. The basic assumption that has to go, though, is that a core application like VSCode can be written once, then be extended to infinity without the core evolving. That's an assumption you see everywhere in extension systems, and it restricts everything to "features or security, but not both".
Taking your examples:
> run a locally installed linter
VSCode and its extensions have certain files opened. The linter can do much less if it gets read-only access to those files, but not write access and no other files, not the open internet or something.
This has then to be coupled with those permissions being displayed before installing, allowing them to be reviewed by users as well as plugin repo curators. Basically listing those permissions as declarative metadata.
Because then a user or curator won't see "this plugin can read and write all your files" but "this plugin can read (but not write) the files being opened by VSCode". If the plugin wants to exfiltrate those files, the permissions would also list "this plugin can send HTTP requests to totally-legit-site.ru" instead of "this plugin gets arbitrary internet access".
Main lession: permissions are WAY too coarse. But if they are fine-grained, they will soon no longer match the evolution of extensions, so the core system has to evolve too.
> view the status of docker containers
"This plugin can view the status of all docker containers started by other VSCode extensions in the same VSCode window".
> users will scream and cry about extensions being limited
Are those the same users? We might need two different products here, "feature VSCode" and "secure VSCode".