Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bleepingcomputer.com

Post reply on HN
Print view View original

441–450 of 488 posts

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

#441

Post by insanitybit »

gchamonlive wrote: post #393
jakemm wrote: 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 proble…

Sufficient for what? It's sufficient for preventing an extension from accessing tokens on my filesystem, from connecting to arbitrary networks, stealing my browser session cookies, etc. It's sufficient for a fucking lot.

This is how browsers have been doing things for 20 years, it's ridiculous that a company worth billions isn't doing it.

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

#442

Post by insanitybit »

panzi wrote: post #381
jakemm wrote: 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

On one hand yes, sandbox everything. On the other the extensions still can change your code which you then run. Though you might only run it in a container at first. I heared zed sandboxes extensions. I should have a look at that editor some day.

Not every extension needs the ability to change your code, let alone change it without user interaction - similar to how iframe sandboxing can allow top level page navigations with user consent.

Also, modifying my code is far better than just launching, stealing everything silently, and having full control over my system. Needing to inject some sort of malware into an arbitrary project is way better.

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

#443

Post by insanitybit »

coldtea wrote: post #383
zuhsetaqi wrote: post #340

Earlier quoted context omitted.

I'm also currently trying to switch from VS Code to Zed and my biggest hope was a better performing editor. The startup time is way better but the typing input is so laggy on my 2018 MacBook Pro 15". It's far worse than VS Code. Also the power usage of Zed is high.

If it uses npm plugins, it's the same crap you get with vscode, just with a rust facade.

Zed plugins are wasm / somewhat isolated. LSPs are not sandboxed, but that's a massive reduction - trusting the LSP is far different from trusting arbitrary extensions.

The system is immature but it's directionally correct.

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

#444

Post by insanitybit »

Balinares wrote: post #277
camkego wrote: post #258

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…

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

Zed plugins execute in wasm. LSPs execute outside of any sandbox, but that's still an obvious win. Your link isn't particularly relevant to an LSP unless the LSP itself is compromised.

Hopefully the system matures with time, but at least they're taking the problem seriously.

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

#445

Post by thewebguyd »

wvh wrote: post #369

I've been telling less computer literate folks not to install random stuff since the nineties, and I can't understand how many devs are doing just that these days. I used to work in security auditing, and it makes me feel pretty jaded to think of the gigabytes upon gigabytes of random stuff that just gets pulled in from everywhere in IDEs, package managers, build pipelines and container images. At least back then the…

> I can't understand how many devs are doing just that these days.

Convenience, and as someone who has been on the other side of the fence his whole career (sysadmin + security), dev != tech savvy. Even during my days in the help desk, the devs were some of the most difficult users to support. Being good at developing software doesn't always equate to being good at operating computer systems, especially in an enterprise environment.

It used to be, dev workstations and environments were fully IT controlled and curated. Then everyone moaned and complained about not having local admin access to their machine (I get it, it sucks and is annoying, but there is a reason), and then devtools started dumping themselves in %APPDATA& and user directories to bypass the admin requirement for installs. And now extensions are in everything, and IT has no tools to control it.

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

#446

Post by skydhash »

simiones wrote: post #437
skydhash wrote: post #433

Earlier quoted context omitted.

It’s not. The developer never build a package and then upload on melpa. Melpa will fetch the needed files and build the package. It’s not truly secure, but an attacker would need to publish a new commit and wait for quite some time for people to update. Another thing is that some packages are old. Seeing an update out of the blue would be very strange. And for packages that are updated more often, I guess the maintai…

My point is, if I want to create a malicious Emacs plugin, I can do the following: 1. Create a new Emacs package, create a PR to register my GitHub repo as a new package in MELPA's repo, and wait for them to accept the PR. Ideally the plugin should be benign at this point. 2. Wait for people to pick up this new extension, while it's still benign. 3. Push the malicious version to my own GitHub repo. MELPA will automat…

> 2. Wait for people to pick up this new extension, while it's still benign

Good luck on that. Check the most popular packages and they all belong to fairly well known people in the community. If it’s something small, people usually just copy the relevant bit to their config. And rarely do huge systems pick up users without active advocacy (helm, ivy, vertico, company, magit, consult, hyperbole, emms, org-mode,…) which means collaboration and plenty of people looking at upstream.

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

#447

Post by AlienRobot »

sunshine-o wrote: post #400
felooboolooomba wrote: post #395

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 dow…

Just prevent VS Code from accessing the entire $HOME.

The idea is that a well-made, modern desktop operating system would extremely limit an executable's access to user files and provide intuitive tools to allow access. Most applications shouldn't even need any access beyond their own configuration directory and maybe something like ~/Document/Source Code for source code editors and IDE. It shouldn't need to access ~/Pictures, ~/Videos, ~/Downloads, etc.

The problem is that Windows would rather sell you OneDrive, and Linux is very far from a well-made modern desktop OS, so a transitive dependency on a linter installed by a VS Code plugin can rm -rf $HOME, I guess.

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

#448

Post by gchamonlive »

insanitybit wrote: post #441
gchamonlive wrote: post #393

Earlier quoted context omitted.

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 proble…

Sufficient for what? It's sufficient for preventing an extension from accessing tokens on my filesystem, from connecting to arbitrary networks, stealing my browser session cookies, etc. It's sufficient for a fucking lot . This is how browsers have been doing things for 20 years, it's ridiculous that a company worth billions isn't doing it.

Don't know what you are talking about, browser extensions implement granular permissions on top of sandboxing too.

https://developer.chrome.com/docs/extensions/reference/permi... https://support.mozilla.org/en-US/kb/manage-optional-permiss...

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

#449

Post by simiones »

skydhash wrote: post #446
simiones wrote: post #437

Earlier quoted context omitted.

My point is, if I want to create a malicious Emacs plugin, I can do the following: 1. Create a new Emacs package, create a PR to register my GitHub repo as a new package in MELPA's repo, and wait for them to accept the PR. Ideally the plugin should be benign at this point. 2. Wait for people to pick up this new extension, while it's still benign. 3. Push the malicious version to my own GitHub repo. MELPA will automat…

> 2. Wait for people to pick up this new extension, while it's still benign Good luck on that. Check the most popular packages and they all belong to fairly well known people in the community. If it’s something small, people usually just copy the relevant bit to their config. And rarely do huge systems pick up users without active advocacy (helm, ivy, vertico, company, magit, consult, hyperbole, emms, org-mode,…) whi…

Sure, but this is just an accident of Emacs being a much more niche product, not related in any way to the design of the package system. If Emacs suddenly gained VSCode's popularity, I can assure you that numerous new users would simply look through MELPA and pick up packages that sound useful, and quickly end up picking up malware - nothing in Emacs prevents this any more than VSCode.

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

#450

Post by TheFlyingFish »

rTX5CMRXIfFG wrote: post #436
Sweepi wrote: post #374

Earlier quoted context omitted.

Answer: Because the "random stuff" (plugins for VS Code and other IDEs) solves real problems and nothing bad happens most of the time. Almost no manager will sign-off spending time on building stuff in-house if its available "for free". This is also in no way a new thing. How much code was written in notepad++ in the '00ies? Did anyone bother to check if the plugins did sth. malicious? We also used some weird closed-…

> solves real problems and nothing bad happens most of the time Aaand this is why AI is taking our jobs and we all rightfully deserve to be laid off. This utter lack of risk awareness and care for quality is what created the need for autonomous agents to dig through and build upon man-made slop. Honestly, I find it rich that we’re the ones who think that AI is the one that’s producing slop. Give any agent clear harne…

Are you suggesting that AI-written code tends to be more secure than human-written code? Because there are many examples to the contrary, starting with MoltBook.
Post reply on HN