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

451–460 of 488 posts

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

#451

Post by insanitybit »

gchamonlive wrote: post #448
insanitybit wrote: post #441

Earlier quoted context omitted.

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

Perhaps I was unclear. I am suggesting exactly that browsers do this correctly and that vscode should be following that old, tried and true model.

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

#452

Post by vlovich123 »

moring wrote: post #286
vlovich123 wrote: post #254

Earlier quoted context omitted.

I don’t know what linters you use, but the ones I like are the ones that show you problems in the workspace stably, not just in the files that happen to be open and altering as files open and close. You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.

This was bad wording on my part. I wrote "open" but that should have been "files in the workspace/project". Really, "open" WRT files is so overloaded already, they can be in the workspace, have an editor tab open for them, or have an active file handle, to name just three. > You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done. I claimed that it is poss…

Im highlighting that defining that sandbox policy cohesively in a way that works for all the different extensions types you’d want to support and doesn’t overwhelm the user with permission fatigue is difficult as to be impossible.

Browsers have a different problem - they protect different websites against each other. The IDE should probably protect you against extensions being able to access arbitrary files on disk, but even that’s difficult (eg a bundled linter often wants to read user defaults in a central location. But protecting even further than that is even harder, especially as here where the access was to the actual repo not anything else.

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

#453

Post by skydhash »

simiones wrote: post #449
skydhash wrote: post #446

Earlier quoted context omitted.

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

> 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

But the issue is not new users picking up unconfirmed packages. It’s about active employees getting compromised by extensions they trusted. As the nature of packages update is opaque and the default settings leave you vulnerable.

If you go on magit’s page on melpa, you get the commit id used for the build and if you wanted too, you could diff the files with upstream. Everything is transparent. Meanwhile what you got on marketplace is whatever is pushed by a token.

And another nice thing about packaging system like emacs is that they rely on peer dependencies instead of pulling their own from the internet. Which is nice, because when a bug is patched, you update that single dependency and you’re done. No need to update every package that depends on it.

[0]: https://melpa.org/#/magit

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

#454

Post by jon-wood »

mfro wrote: post #410
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…

FWIW VScode can be used in a docker container or remote server from the local client. See devcontainers and VSCode over ssh.

At least some of your extensions will still run in the client editor instance, not on the server side. That limits exposure a bit but when colour themes have been known attack vectors in VSCode it’s far from a panacea.

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

#455

Post by rTX5CMRXIfFG »

TheFlyingFish wrote: post #450
rTX5CMRXIfFG wrote: post #436

Earlier quoted context omitted.

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

Not really, no. That's not even the point. Say for example they're just the same level of security. Then what value does a human even offer to a company if AI can do the same quality of work faster? It's not as if the company benefits from something like "human discernment", because as predicated in this thread, developers exactly have none of that, since they don't care about the security aspect of the VSCode extensions that they use. Might as well lay off the human developers and just use AI for as long as the latter is cheaper. How many people does a company really need to update its VSCode to the version that blocks the malicious extension? Do you need more than one and does that person have to be full-time?

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

#456

Post by dgellow »

gabrielgio wrote: post #356
dgellow wrote: post #353

Earlier quoted context omitted.

Im pretty sure GitHub reliability issues are a result of Microsoft centralized management (i.e migrate everything to azure, the only allowed cloud)

Tbh, at this point why does it matter if it was MS or not?

I don’t think it does, I was just pointing out their issues are likely caused by the centralized resource managementent (mentioned by https://news.ycombinator.com/item?id=48219114 you responded to), and not the „move fast, break things“ aspect. Just my guess. But yeah, it doesn’t matter if it is MS or GitHub itself

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

#457

Post by neop1x »

AlienRobot wrote: post #447
sunshine-o wrote: post #400

Earlier quoted context omitted.

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

For linux we have bubblewrap, firejail, apparmor and selinux (popular ones, there are far more). But it is often complicated and annoying to set up. Normally one would expect sw developers would write security rules for their apps but it is difficult due to amount of different sandboxing tools and various distro-specific configuration changes.

It would be nice to have it sorted out somehow. Actually Snap is an interesting example of something done in that regard.

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

#458

Post by AlienRobot »

neop1x wrote: post #457
AlienRobot wrote: post #447

Earlier quoted context omitted.

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

For linux we have bubblewrap, firejail, apparmor and selinux (popular ones, there are far more). But it is often complicated and annoying to set up. Normally one would expect sw developers would write security rules for their apps but it is difficult due to amount of different sandboxing tools and various distro-specific configuration changes. It would be nice to have it sorted out somehow. Actually Snap is an intere…

Yes, and I wish Linux developers would see their own hypocrisy.

Linux users love to say that "fragmentation is good" but they also depend fully on root, sudo, users/groups, and RWX file permissions. Those are "standards" enforced by having only 1 way of doing something, the kernel.

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

#459

Post by atq2119 »

larusso wrote: post #244
atq2119 wrote: post #192

Earlier quoted context omitted.

Internet access. An editor extension does not need it.

Most sandbox systems today, take seatbelt from Apple for instance, only strip permissions. If your extensions without internet access calls a tool that needs it, boom access denied or worse, weird network issues. One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.

Sure, that's the main challenge with building good sandboxing systems. But it's not actually that hard to do when the will to do it is there.

For example, Android already allows you to give apps restricted access to your media. My understanding of the way it works is that the resulting interface for picking photos etc. is not under the control of the app. The app only receives whatever file you picked.

Post reply on HN