Live data from Hacker News

Malicious VSCode extensions with more than 45k installs

blog.checkpoint.com

31–40 of 191 posts

Re: Malicious VSCode extensions with more than 45k installs

#31
post #3

This is one of the reasons I am *very* hesitant with VS Code extensions and Jetbrains plugins. The absolute minimum is strictly enforced on all my machines. Ditto for project dependencies (NPM, PyPi, Gradle etc.) However, the way things are going, news of these vulnerabilities / incidents will be used to push through the Codespaces (IDE on the cloud) among enterprises -- and many companies will fall for it. I guess s…

My God, the list of npm dependencies some projects I've worked on had. Endless. Anyway, it could have been me. I don't inspect vim plugins before install, generally. Security is hard. Even if you're an expert, it's a lot of work.

As a bare minimum security measure, when using plugins (all 9 of them), my Vim runs in a bubblewrap sandbox with only my project folder mounted as writable. Network and IPC access is completely disabled. It is secure enough to stop practically all non-targeted attacks.

Generally I try to install plugins whose authors I know. And whenever I update them (once a year) I re-read the entire source code. Some small plugins I just integrate in vimrc directly.

I hate to say this but Vim isn't the most secure editor, considering features like modelines which some environments enable by default and an aggressive plugin installing culture.

Re: Malicious VSCode extensions with more than 45k installs

#32

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 agree that would be a tough business model. Even for a relatively small package set like VS Code plugins there must be many thousands of releases to check every year and the potential market of paying customers for the tool is limited. Maybe it could work if some of the tech giants sponsored it?

For the wider problem of depending on external packages and managers like pip or npm I don't see how anyone could realistically keep up with the scale of releases that would need to be checked. You would need far fewer packages from far fewer sources with far less frequent releases for this to be a viable strategy. That might be nicer for developers for other reasons as well but it's not the world we live in today.

Re: Malicious VSCode extensions with more than 45k installs

#33
post #28

Earlier quoted context omitted.

This is even more true considering that VS Code sends telemetry by default (opt-out), making it as a whole "malicious PII stealer code" in the article's terms.

Not really, if you are aware of that and have been actively been opting out of vscode telemetry it is downright malicious of addons to do it behind your back anyway.

If a product forces you to opt-out from telemetry, it makes sense that extensions would approach the problem the same way and force you to opt-out from each extension's telemetry.

I'm not saying that's good, just that it makes sense that whatever ecosystem/community spawns from your product, they adopt the same methodology as the main product uses.

Re: Malicious VSCode extensions with more than 45k installs

#34
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.…

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 systemd DNS resolver via DBUS and exporting your keys as DNS requests).

Security is a joke in Linux in default configuration.

> . It should be an obvious red flag if a [theming addon] were to ask for those dependencies

No. Theming addons should not even be able to ask for those privileges.

Re: Malicious VSCode extensions with more than 45k installs

#35
post #22
post #21

I always find this question interesting. Is there a money to be made in a company that main purpose would be to provide periodic check on the source code dependencies. So that for a certain amount of payment, you get to submit a list of dependencies and they monitor the source code and give a report with that changes, problems and security issues. So it is like a Source code check as a service.

I think this is what WhiteSource does. (it's also apparently called Mend now)

Not only are the products confusing (which one does what parent mentioned?) but that pricing is out of reach for so many I'm wondering if the company is actually real or not?

Cheapest plan starts at 1333 USD per month!

Re: Malicious VSCode extensions with more than 45k installs

#36
post #28

Earlier quoted context omitted.

This is even more true considering that VS Code sends telemetry by default (opt-out), making it as a whole "malicious PII stealer code" in the article's terms.

Not really, if you are aware of that and have been actively been opting out of vscode telemetry it is downright malicious of addons to do it behind your back anyway.

It would be good if VSCode asked you which permissions a plugin should have. E.g. a lot of plugins shouldn't be talking to the internet, writing to disk or similar in the first place. And if they do you should be able to whitelist what they're allowed to access.

Re: Malicious VSCode extensions with more than 45k installs

#37

Earlier quoted context omitted.

> I guess software engineers and technical experts cannot be trusted anymore to keep their machines safe. :-/ I think we never could in the first place? While we are more cautious than the average user, we might occasionally shoot ourself in the foot. That’s part of our job. The extensions shown in this example would not have ended up on my machine, simply because of the red flags they come with.

Are we more cautious? We might not fall for the old scam of extension bars in the browser and approving spam notifications but I'm sure plenty of people would blindly follow a tutorial to run commands in the terminal and install dependencies to run code. The most recent example was probably Win 11 replacing the status bar and people recommending all kinds of anonymous software on GitHub. It's open source and works so…

Plenty of popular developer-friendly tools have installation instructions that involve sudo, curl and piping to sh. That says everything we need to know. But if it didn't then the way many developers will casually install packages from untrusted third parties when the installation scripts themselves could do almost anything says the rest.

In addition developer PCs often have more privileges than a typical office worker. That's legitimately useful for our work but also means compromising a developer machine is a bigger risk. We're a nightmare for any organisation that wants proper IT security.

Re: Malicious VSCode extensions with more than 45k installs

#38
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.…

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.

Re: Malicious VSCode extensions with more than 45k installs

#39

This is one of the reasons I am *very* hesitant with VS Code extensions and Jetbrains plugins. The absolute minimum is strictly enforced on all my machines. Ditto for project dependencies (NPM, PyPi, Gradle etc.) However, the way things are going, news of these vulnerabilities / incidents will be used to push through the Codespaces (IDE on the cloud) among enterprises -- and many companies will fall for it. I guess s…

I think if it's a large org you should treat engineer machines as threat vectors by default, PoLP and all that jazz. Someone already posted here how they were able to use PIP to hijack Google developer machines because on their machines defaults were to resolve to public repo first (even for private packages). Google just closed/ignored the issue because this was engineers problem and official build was setup to reso…

If you apply principle of least privilege to developers then ideally you should have a whitelist of every software package that they need to use. What happens then when a productive developer, instead of developing from scratch, searches for a solution to some problem and discovers that there is already a module that may solve it? Do they go to some central committe to get approval to add it to the whitelist? What are their criteria? How long will it take them to approve it?

Suppose it takes a couple of days. Then the developer tries the module. Discovers immediately that the module doesn't solve the problem. That's two days wasted for nothing.

Suppose some module that has dependencies on a huge list of other modules. How long will it take now?

I'm not saying polp isn't valid. But is it practical?

Re: Malicious VSCode extensions with more than 45k installs

#40
Vscode was always going to attract such issues. On my system, the app does not have access to the home directory and everything is done on a remote container that I locally ssh into (thanks to flatpak's bubblewrap and docker). As a result everything is cleaner and vscode is isolated from the host.

Access to local folders on the host (though rare) is approved on a needs basis.

Post reply on HN