This 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 malicious or not may shape how you feel, but let's be honest, there's a world of difference between sending your OS versions to a telemetry server and injecting obfuscated code.
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.
This is my thinking exactly. If you put exploit code in there in day one, you are likely to be found out quickly. But if you wait until you detect a valuable target, test the waters with a non-malicious update, then you can probably distribute the malicious update to run in a targeted fashion, perhaps even rolling it back shortly after to reduce later forensic investigation.
We need to stop treating our dev tools like they are trusted. They are not, and they rely more and more on networks of even less trustworthy code. That VSCOde doesn’t have a proper sandbox or TCB for its plugins is pretty damning.
> collects some data that I would define as telemetry
Maybe the platform and os can be described as "telemetry", but logging the hostname definitely counts as stealing private data!
Apple by default uses the user's name as host name (eg. "John-Does-Macbook-Air.local"), so you could use this to determine if a specific person has installed your extension.
That is spyware, not telemetry.
The malicious extension could then, once it has determined a specific target user has installed the extension, ship a malicious update.
Before you go down this rabbit hole, consider that many extensions are slight forks of others. There isn't always malicious intent. Just people who try to extend the extensions and publish them without knowing otherwise.
For example go look at any popular "Hello world" type of extension and you'll see many results of extensions in this definition of "name squatting".
When you add telemetry to a fork of a thing that didn't previously have telemetry, you don't deserve the benefit of doubt. The original didn't need telemetry, so neither does your fork. Anybody who does this should be assumed malicious.
And telemetry for a fucking color theme? You've got shitting me. Whoever did this is a Grade-A scumbag. It didn't happen by accident and there is no possible benign motivation for it. I hope somebody has reported this to the FBI and other relevant authorities.
Non-malicious forks would choose a completely different name and mention the original in their README.
Name squatting relies on people making a typo and installing your stuff. That cannot be innocent, come on now.
Your link also does not prove anything except that people naively make extensions with the same name that feels cute or easily discoverable to them. I see no name squatting in that list, not in the top 10-20 anyway.
> Name squatting relies on people making a typo and installing your stuff. That cannot be innocent, come on now.
You are thinking of typosquatting. And my example shows people can publish extensions squatting on the same extension name as established ones while also changing other metadata to impersonate or spoof popular ones and confuse users quickly looking to install the extension.
But it does imply a trust and quality issue with the VSCode marketplace.
Combined with the lack of a proper sandbox or TCB for plugins, having an untrustworthy “marketplace” makes VSCode sound like a disaster waiting to be installed.
Another opinion is that there is plenty of crap on every registry and some are better at surfacing and cleaning up than others.
Similar to the US Navy and ships that are rust-free versus those battling rust. It doesn't affect the performance of those ships, just the perception. Left on for too long could eat away the actual integrity.
Not all problems are the registry's to burden. Trust and quality decisions are very individual for example. There's no same definition used between two people.
VSCode doesn’t even provide a framework for enabling that decision making. Sure, you could forgo the use of any plugins, but so much of VScode’s functionality is derived from plugins, you’d be better off just using notepad.
To be fair, vim and emacs aren’t any better.
Most of our dev tools are based on plug-in models that have zero security model baked in.
Most of those are social signals, and social engineering is a thing. Sure, you can read the code for every single update for every single plug-in you have to use for VSCode to function.
Having a proper set of API boundaries with security guarantees is the right solution. Even “notable publishers” can get hacked.
I don’t even understand why it’s an open question, tbh.
Darcula Dark could easily be what it says it is, which is an innocent take on the VS Code’s default Darcula theme. I’d be willing to bet there are innocent VSCode extensions with Darcula in the title, and I don’t think that’s unreasonable or traitorous of any kind of intent
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.
It makes more sense that the extension would check the configured telemetry enablement state and use that. Perhaps provide an extension-specific override, but certainly don’t default to anything besides the global value.
This is what happens if you use the first party telemetry module msft provides, but obviously not if you’re just sending random http requests.
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 access to the host platform, to do whatever they want. This is what VSCode and many others do, which comes with a lot of issues regarding security, but plugin authors can essentially do whatever they want.
The first approach requires a lot of careful consideration, development time and maintenance, while leading also to a somewhat locked down environment. It's more secure, but also limits the usefulness of some extensions.
Microsoft, in their usual lazy fashion, chose the latter approach, probably because it makes the most money sense. Why spend a lot of development time (and money) when you can do it faster and for less money? Some security holes won't lose you a ton of money, but spending N developers building a proper plugin API will for sure cost you a ton of money.
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.
- 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?
Certainly not the worst approach, but it might turn out far less watertight than hoped. E.g. plenty of places in html-based UI where you can sneak in an URL that pulls some image, with all the data sent upstream you can fit in a GET. And good luck noticing, when everything is on https and someone decided that certificates should be pinned.
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 malicious or not may shape how you feel, but let's be honest, there's a world of difference between sending your OS versions to a telemetry server and injecting obfuscated code.