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

Malicious VSCode extensions with more than 45k installs

blog.checkpoint.com

Post reply on HN
Print view View original

111–120 of 191 posts

Re: Malicious VSCode extensions with more than 45k installs

#111

Post by explaininjs »

Gigachad wrote: post #79
carlmr wrote: post #43

Earlier quoted context omitted.

I'd say VSCode is a bit different in who it's aimed at. Only because it doesn't work for a consumer product doesn't mean this wouldn't work for VSCode. Also it might be good to be more specific. E.g. don't ask for all permissions at once, instead if the app starts talking to telemetry.endpoint.com it has to ask for these specific permissions at that point. Then the user can see, hey this is requesting access to this…

Are VSCode users really that much more diligent? Are you auditing the source code for every extension you install? Do you even know if the github source is the same as whats hosted on the plugins repo? The only real solution I can see is only installing plugins from large trusted entities.

For sketch extensions, download the vsix from the marketplace and extract it (it’s just a zip), then inspect that and load it.

Re: Malicious VSCode extensions with more than 45k installs

#112

Post by medo-bear »

rollcat wrote: post #86
anthk wrote: post #71

Earlier quoted context omitted.

So it's Emacs, but we want features and not to be locked. Don't run propietary crap, trust Elisp repo like ELPA and NonGNU and you will be mostly safe.

Isn't MELPA just serving the latest git master of whatever it happens to be at the time package-refresh-contents was called? With MELPA stable likewise just serving the latest tag? That doesn't spell trust.

Using Emacs is not going to help you to avoid supply chain attacks per se. What it might do, however, is give you unparalleled power to inspect your environment - calls and source. If you run untrusted code you are exposed, and thats that. Development tools should assume that you, a programmer, know what you are programming.

Emacs and lisp is focused on providing power, not security. These often do not go hand in hand.

Re: Malicious VSCode extensions with more than 45k installs

#113

Post by jakear »

itsamy wrote: post #85

I'll take the opportunity to self plug: I've been working on a solution to help bridge this gap of having to blindly trust VSCode extensions, planning to eventually also release it as open source You're welcome to sign up for early access at https://coderguard.io/ As I'm currently mainly looking for user feedback

Looks interesting, I used to work on the vscode team, lmk if there’s anything I might help with.

Re: Malicious VSCode extensions with more than 45k installs

#115

Post by PoignardAzur »

oofsa wrote: post #84
fwlr wrote: post #19

Capabilities-based security prevents these supply chain attacks! (Even though in this case most of the downloads were of packages including unwanted telemetry and not something more dangerous.) “…And now if a [color theme] wants to read your data and send it to a server, it needs a filesystem capability and a network capability. It should be an obvious red flag if a [theming addon] were to ask for those dependencies.…

I want that feature too, but in reality, many non-trivial extensions require the execution of binaries such as language servers. Applying capability models to these executables will require OS support or containerization, but the overhead for memory and disk will be huge. In fact, even an extension to auto-complete paths in .gitignore files requires running a language server written in Rust [1], and it has the real b…

Couldn't you just run the language server in webassembly?

Re: Malicious VSCode extensions with more than 45k installs

#116

Post by wcoenen »

capableweb wrote: post #38
codedokode wrote: post #34

Earlier quoted context omitted.

Yes! Sadly, today nobody seem to care about the principle of least privileges. Take Linux as an example: every program you install gets full access to the system, and gets thousands of privileges it doesn't need. If your PDF reader is vulnerable, it will have both access to your SSH keys and to the Internet to upload them (and if you block Internet access for a PDF reader, it still can send the data by connecting to…

At least there is practiced, hardened and battle-tested tools that are relatively straight-forward to use in Linux-land, like AppArmor. MacOS also recently started investing more into securing the desktops of developers. Windows seems shit out of luck in that regards.

I'm not sure whether it does what you want, but Windows has "Windows Sandbox":

https://learn.microsoft.com/en-us/windows/security/threat-pr...

Re: Malicious VSCode extensions with more than 45k installs

#117

Post by qup »

throwaway290 wrote: post #56
maccard wrote: post #15

Earlier quoted context omitted.

Do you check _their_ dependencies though? And do you check every file?

I don't check every file but I use very sophisticated proprietary heuristics such as "intuition" and "hunch" for how far to dig. I use vim so dependencies are explicit. But when using npm packages in work I give dependencies a look before I look anywhere else. An unfamiliar dependency gets looked at. It's easier since npm web browser allows inspecting code. It's a very imperfect process.

Have you ever caught anything?

Re: Malicious VSCode extensions with more than 45k installs

#118

Post by marcosdumay »

Gigachad wrote: post #24
fwlr wrote: post #19

Capabilities-based security prevents these supply chain attacks! (Even though in this case most of the downloads were of packages including unwanted telemetry and not something more dangerous.) “…And now if a [color theme] wants to read your data and send it to a server, it needs a filesystem capability and a network capability. It should be an obvious red flag if a [theming addon] were to ask for those dependencies.…

Yeah, android tried this initially with the permissions system. But literally every app requested every permission and it became completely useless. As a user, you have no way of meaningfully using this info.

> But literally every app requested every permission

They didn't. Google regrouped and renamed the permissions until every normal thing that every application needed became grouped with rare and powerful capabilities.

Except for the ad-based crapware, almost all applications minimize their permissions.

Re: Malicious VSCode extensions with more than 45k installs

#119

Post by dylan604 »

bdcravens wrote: post #114

2 out of the 3 examples do not have more than 45k installs. The one example that did "had a simple PII stealer code" but was actually just sending telemetry. The point of the article is probably valid, but the article itself seems to be dishonest.

Does the 45k installs mean for a specific extension or just that 45k installs in total of all extensions?

Re: Malicious VSCode extensions with more than 45k installs

#120

Post by afiori »

imoverclocked wrote: post #20
samwillis wrote: post #7

Earlier quoted context omitted.

There must be a huge market for "audited and validated" subsets of the major package managers. For a monthly fee you have access to a secure version where all dependancies are checked (manually, or automatically) for vulnerabilities and where no new packages, or versions, can be added without having eyes over by a human. Throw in a credits or fees system where you can request, for a cost, a none audited package is ad…

Sure, but the business model for the entity providing that sucks. Practically infinite amounts of possible exploits and extremely finite resources to detect them. Either that or you are back to where you started with a web of trust.

I could be a "risk assesment" service. For a given package it could run an automated web-of-trust on it together with an analysis of past history of vulnerabilities and of its mantainers.

You can also add watchers to check who is allowed to publish new versions ad see when that list changes.

Even without looking at the code you could gather a useful report.

Post reply on HN