Live data from Hacker News

GitHub confirms breach of 3,800 repos via malicious VSCode extension

bleepingcomputer.com

391–400 of 488 posts

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#391

The security model, or almost lack of any whatsoever in VSCode drove me to only install MSFT extensions, then use Code Server in a docker container, but I decided I didn’t like using my editor in a browser. Finally I have decided to start using Zed, which isn’t perfect on the security front, but much better IMHO. The combination of WASM extensions, and the ability to put language servers, etc, in dev-containers seems…

> I hope Zed continues to improve their extension and language server security model.

To be honest I doubt there's much that they can do. Many many language servers cannot run in WASM, or it would be super hard to compile them to WASM. So Zed either has to allow running arbitrary binaries like VSCode, or accept that they're going to have really poor extension support.

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#392

Note that VS Code is built on Electron and it is a pain to sandbox because Electron has (had?) SUID sandbox helper, and you cannot run SUID binaries in sandbox easily. Sandboxing on Linux is extremely difficult task.

> Sandboxing on Linux is extremely difficult task.

Which is really insane when you think about it. Plan 9 had this sorted out decades ago.

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#393
post #336

There is a Feature request from 2018 that I have been following for a long time to ask for VSCode Sadbox. I do not understand how Microsoft is not putting it up in priority. https://github.com/microsoft/vscode/issues/52116

Sandbox alone isn't sufficient because when loading a malicious extension into a session you might be exposing your environment variables to it. You also need explicit permissions, so that only relevant extensions can access secrets like this.

And even if this exists, and you are sandboxed, with all guardrails and such, if you trust an extension that later gets compromised, you'd get the same sadness. It's the problems with trusting trust all over again...

Maybe sandboxing, plus freezing updates for at least a week, then on each update reviewing the permissions for each extension, then reviewing the extension itself for compromises. Something that should be done not by the user but by the supply chain itself.

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#394

Earlier quoted context omitted.

I really hope this pushes users (here: devs and maintainers) to decrease their reliance on Microsoft and especially stop outsourcing security to them. Migrate off vscode already.

There's nothing really special about VSCode here, except that it's really popular. You could just as easily attack Emacs or Vim or Sublime or [...] users by distributing a malicious extension.

You can’t attack them that easily because of the different publication method. Emacs, Vim, and Sublime have a pull model (like linux distros), not a push model. Meaning you add your repos to the package hub, you do not upload an archive to them. The Hub will pull in you changes (or the plugin manager will do so). The only way in is to take over the repo itself.

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#396
post #209

Earlier quoted context omitted.

Agreed. What's frustrating is that we have models for how sandboxing can work and instead of investing efforts into nailing that experience, the OS providers are prone to turning it into a monetization/lock in layer instead. My VLC and VS Code should have an OS native way of being limited to particular functionality. But when the OS providers implement the sandbox, they center it around an App Store and restrictions…

> My VLC and VS Code should have an OS native way of being limited to particular functionality. The problem is... it's hard to scope. A media suite such as VLC, simply by what it is intended to do, needs a lot of permissions. Read data from physical media drives (CD/DVD/BD), preferably directly against the device to circumvent DRM. Access the network 0.0.0.0/0 1-65536 TCP and UDP to be able to play all sorts of strea…

A viable strategy is something like qubeos for isolating activities from each other. You can have a media vm, a dev vm, a bank vm, and a password/manager vm. Or you use different computers.

I think one issues has been having code hosting/build systems/deployment pipelines under one ecosystem with non scoped keys. Especially your deployment keys should be on a service that only interacts with inert archive (no building or downloading anything).

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#397

Earlier quoted context omitted.

Wait, how do you arrive at the thought that Zed is more secure? The one time I gave it a try, it tried to silently run npm -- yes, THIS[1] npm -- in the background without telling me, and I noped the heck out. Did I miss something? [1] https://www.reddit.com/r/programming/comments/1tapmvi/mass_n...

Pretty sure any IDE worth anything that has JS support pulls NPM packages at some point to lint code, no? You're not giving me much to be outraged about without more information. Zed tries to set things up for you so you're not wasting hours trying to figure out how to set them up in a brand new editor.

I do not use JS and certainly was not doing anything JS-related, and I do very much not expect my tooling to silently run code from insecure Internet sources on my machine. Which does not seem like an outlandish position to me? If you consider that acceptable, yourself -- fair enough, that's your call and it's your machine, but let's please not label that anything but grossly insecure?

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#398
post #240

Earlier quoted context omitted.

> Migrate off vscode already. Zed is the closest thing I've found to meet my needs, and I do plan to try it. However it's dev container support looks to be lacking in some important ways so we'll see.

Let me save you some hassle. I test drove Zed for a week after the v1.0 release. My projects deal exclusively in dev containers. I spent more time troubleshooting issues than actually working. Things which VS Code handles transparently, like installing the support libraries to run a chrome debug session, say. Your local SSH agent isn’t forwarded into the container, so git push doesn’t work natively. That’s after you’…

Thanks, after seeing this and others talk about it silently installing node and other tools that's enough for me to dismiss it as a viable option.

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#399
hmm I created my project based on malicious browser extensions. But I am starting to think that I should make it more broad and look at VSCode extensions too.

I keep reading about vscode extensions going malicious and I feel the same way as I did when I was reading (and still am) about all the malicious browser extensions. I don't understand the lack of security around "extensions" in all sectors..

Re: GitHub confirms breach of 3,800 repos via malicious VSCode extension

#400

In addition, we need a fundamental change in OS security. It's not OK that every application you run has access to all your files and unfiltered internet access by default.

Security mechanisms in most operating systems are good and has continued to evolve rapidly. I would say in Linux there might be too many and this is where the confusion come from.

The problem is really how the very popular recent things on top have been built: Docker, npm, pip.

I personally do not have docker, npm or pip installed on my workstation because I know that any `xxx install` is almost the equivalent of downloading and executing a `.exe` on a Windows 95 back in the days.

Apparently what happened here is a Github employee VScode downloaded a compromised extension and it ran wild in his $HOME (npm, another Microsoft gem is involved here if I remember correctly).

How was the OS supposed to prevent that?

Post reply on HN