Three welcome dialogs at once, enable notifications, cookies and bot wanting to chat plus the crappy low resolution logo were enough for me to not even start reading. Judging by the comments here I didn't miss anything important.
Malicious VSCode extensions with more than 45k installs
51–60 of 191 posts
Re: Malicious VSCode extensions with more than 45k installs
#52Capabilities-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…
> every program you install gets full access to the system
It gets your user's privileges when you run it. It's up to you how you run your programs.
Also there's no "default Linux configuration". There are many distributions, and they have different defaults and approaches.
Re: Malicious VSCode extensions with more than 45k installs
#53This article is a good example of how to write a misleading headline. They found 3 extensions, one of which has 45k downloads (because it name squats on a popular package), and another with 1000 installs. The 45k dowload extension (Darcula Dark) collects some data that I would define as telemetry, and the python-vscode extension which is clearly trying to hide what it's doing. Now, whether you define telemetry as mal…
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.
And from what I remember VS Code associates your complete MAC address with that telemetry (it applies some ineffective obfuscation).
Re: Malicious VSCode extensions with more than 45k installs
#54Capabilities-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.…
Capabilities can improve the situation significantly but we need to change how we build software too e.g. ".env" files in the project space will still be vulnerable due to the confused deputy problem.
Re: Malicious VSCode extensions with more than 45k installs
#55Earlier quoted context omitted.
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.
Users here are experienced developers, so I think it's not such a big deal. In context, a theme should never need network or file storage access, so you could upfront block those for that type of extension. You can also have policies like "network access is okay but file system and network access together needs approval".
Why are you assuming most VSCode users are "experienced developers"? I would think quite the contrary, as the younger crowd is probably much more likely to be using it than more experienced developers.
Re: Malicious VSCode extensions with more than 45k installs
#56Earlier quoted context omitted.
I always give source code a glance, unless it's by a sufficiently prominent and reputable maintainer.
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.
Re: Malicious VSCode extensions with more than 45k installs
#57Earlier quoted context omitted.
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.
There are generally two ways to go about to enable plugins in whatever you're building: - Clear API boundaries that defines what you can do or not, with each API surface being obsessively guarded in terms of what it lets through. Usually leads to secure extensions but hard (if not impossible) to do things the API authors didn't foresee as it's locked down hard. Figma plugins use this approach. - Give extensions raw a…
How about a third way:
- Give extensions the ability to do whatever they want (in the sense of not requiring them to only call your specific API signatures), but run then in a sandbox, so that they have to ask for access to the internet, filesystem, and so on?
Re: Malicious VSCode extensions with more than 45k installs
#58This article is a good example of how to write a misleading headline. They found 3 extensions, one of which has 45k downloads (because it name squats on a popular package), and another with 1000 installs. The 45k dowload extension (Darcula Dark) collects some data that I would define as telemetry, and the python-vscode extension which is clearly trying to hide what it's doing. Now, whether you define telemetry as mal…
Woah, that's a narrow view.
Name/typo-squatting in inherently malicious as there's intent to deceive. It doesn't matter what code is _currently_ present and that can change at any time.
Besides, think about how you'd maliciously use that telemetry. If the author sees installations coming from intuit.com (for example) then they know they are one auto-update away from having a foothold on a company network with tons of sensitive data. That's a targeted supply-chain attack.
Re: Malicious VSCode extensions with more than 45k installs
#59Earlier quoted context omitted.
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.
There are generally two ways to go about to enable plugins in whatever you're building: - Clear API boundaries that defines what you can do or not, with each API surface being obsessively guarded in terms of what it lets through. Usually leads to secure extensions but hard (if not impossible) to do things the API authors didn't foresee as it's locked down hard. Figma plugins use this approach. - Give extensions raw a…
Actually, the VS Code approach is closer to the first one (Clear API boundaries). VS Code extensions don't have direct access to internals, no direct access to the UI [1], and extensions can control VS Code only via the Extension API [2]. However, extensions have access to many standard JS functionalities that could be used in the wrong way.
By the way, Figma plugins can also send arbitrary information (such as file contents) to external servers.
That said, I think it's good idea to add to extensions permissions/capabilities security like in mobile apps.
P.S. If the Extension API doesn't have what you need, there are Proposed APIs [3], but you can't use them in published extensions, and sometimes proposals move very slowly.
[2] https://code.visualstudio.com/api/extension-capabilities/ove... [1] https://code.visualstudio.com/api/references/vscode-api [3] https://code.visualstudio.com/api/advanced-topics/using-prop...
Re: Malicious VSCode extensions with more than 45k installs
#60This feature request has been sitting around since 2018:
https://github.com/microsoft/vscode/issues/52116
It advocates for treating VSCode extension permissioning like browser extension permissioning.
Of course, it's not a panacea, but it would be lovely to have.
I discovered it when I went searching for a way to disable network access for a particular extension. You can do it, sort of, for VSCode itself, but not for individual extensions.