A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us.
Our security researchers at Microsoft confirmed this claims and found additional suspicious code.
We banned the publisher from the VS Marketplace and removed all of their extensions and uninstalled from all VS Code instances that have this extension running. For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.
Letting you know that VSCode is unable to uninstall the extension. It prompts me to uninstall, but when I confirm the window refreshes and the extension is still there, triggering the same "is problematic" prompt. This is an infinite loop. Same behavior when trying to uninstall the usual way from the extensions panel.
I had to manually delete the extension's folder in %USERPROFILE%\.vscode\extensions and delete the entry from the json (%USERPROFILE%\.vscode\extensions\extensions.json).
> A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us.
> As a reminder, the VS Marketplace continuously invests in security
If you’re relying on the community to alert you to the issues in the marketplace, perhaps you’re not investing enough in auditing popular extensions yourself?
I would also suggest that the trust model for VSCode is fundamentally broken - you’re running arbitrary third party code on client machines without any form of sandboxing. This is a level of security you would not deploy into Azure, so why is “run arbitrary 3p code on someone else’s machine” appropriate for VSCode?
While I appreciate the work that the VSCode team does and I use it, the lack of any form of sandboxing has always bothered me.
PSA: every package you install from any package manager from browser extensions to npm/composer etc presents the risk of malware. Because the open source community lacks the financial resources to vet every single version of every package. Demanding this level of security from software provided at no cost that relies on open contributions is wholly unreasonable. If you need that, buy an IDE from a company financially capable of ensuring security and accept the limitations of their offering.
Mitigations like running in a VM might protect your dev workstation. But not code you put into production that relies on third parties.
Idk if they removed the malicious theme (or if they have it at all), but if MS isn't doing anything beyond just responding to user reports, you might as well switch to an open registry that probably does the same level of security work, and avoid giving them yet another monopoly.
Remember, this is Microsoft! A friend told me of a fairly major corporate firm that found MSFT had arbitrarily pushed an AI tool to run on their SharePoint, scooping up site data outside of any formal agreement to do so. MSFT are no doubt covered by a general agreement but this seems underhand/inept and yet a remarkably common flaw in their approach (I've seen similar behaviour with Teams apps)
> If you’re relying on the community to alert you to the issues in the marketplace, perhaps you’re not investing enough in auditing popular extensions yourself?
I think that's sort of unfair. Of course MS should be relying on the community! That's arguably the best single practice for detecting these kinds of attacks in open source code. Objectively it works rather better even than walled garden environments like the iOS/Android apps stores (which have to be paired with extensive app-level sandboxing and permissions management, something that editor extensions can't use by definition).
The reference case for best practice here is actually the big Linux distros. Red Hat and Canonical and Debian have a long, long track record of shipping secure software. And they did it not on the back of extensive in-house auditing but by relying on the broader community to pre-validate a list of valuable/useful/secure/recommended software which they can then "package".
MS's flaw here, which is shared by NPM and PyPI et. al., is that they want to be a package repository without embracing that kind of upstream community validation. Software authors can walk right in and start distributing junk even though no one's ever heard of them. That has to stop. We need to get back to "we only distribute stuff other people are already using".
> you’re running arbitrary third party code on client machines without any form of sandboxing. This is a level of security you would not deploy into Azure, so why is “run arbitrary 3p code on someone else’s machine” appropriate for VSCode?
More and more, I am starting to think I need to run my development environment (for both work and personal projects) in a VM.
I am on MacOS, so UTM or Parallels would work pretty well I think. Sadly, I think my work explicitly forbids us from running VMs or accessing our services from them.
Thanks. Our security researchers will review this today and we might take it down.
We reached out to the new author and he does not have malicious intent, and agreed that we just take down the new extension if we see something is off.
Hi Isidor, excited for this! At Open VSX, we'd love to take a look and potentially flag the extension as malicious on our side as well. Are you aware of the version range that the malicious code was included in? I'm asking because https://open-vsx.org does not have any version published since the extension went closed-source.
False positives suck, and it hurts when it happens.
The publisher account for Material Theme and Material Theme Icons (Equinusocio) was mistakenly flagged and has now been restored. In the interest of safety, we moved fast and we messed up. We removed these themes because they fired off multiple malware detection indicators inside Microsoft, and our investigation came to the wrong conclusion. We care deeply about the security of the VS Code ecosystem, and acted quickly to protect our users.
I understand that the "Equinusocio" extensions author's frustration and intense reaction, and we hear you. It's bad but sometimes things like this happen. We do our best - we're humans, and we hope to move on from this We will clarify our policy on obfuscated code and we will update our scanners and investigation process to reduce the likelihood of another event like this.
These extensions are safe and have been restored for the VS Code community to enjoy.
Again, we apologize that the author got caught up in the blast radius and we look forward to their future themes and extensions. We've corresponded with him to make these amends and thanked him for his patience.
Scott Hanselman and the Visual Studio Code Marketplace Team - @shanselman
Is it possible for you to add color theme/icon theme/keymap only extensions, without any executable code? I think, it will improve the security situation a bit. I don't see why the mentioned kinds of extensions should have any code.
This is really confusing to me. The original discussion was about changing licenses, but somehow (coincidentally?) there was malicious code discovered shortly after? Are these related?
I did a thorough combing of the code base when I forked. Just did another audit and still not seeing anything suspicious. Gutting all of the opencollective and changelog code to be 1000% sure.
The extension file is still available to download directly from MS.[0] (Which, why if you pull it from users are you still allowing downloads first of all.)
I downloaded the file, and unzipped it. On a cursory glance I see obfuscated code but zero "red flag" level code, has anyone seen the malicious code claimed?
There will never be some permission model. Like in VBA there is after all this years nothing. VBA would be much less problematic if you could restrict VBA to just one Excel sheet or so
Given that it's been automatically removed from all VS Code instance, is there any way to check if it was previously installed? It's concerning that there's now no way to check if a sytem has been compromised by this
I am in European time and I do not know what happened on that post (since I was sleeping). I assume it were some heated arguments between maintainer and community about license/copyrights/open source maintenance.
Hey y'all, I made the most prominent fork of this extension "Material Theme (But I Won't Sue You)"
The maintainer went off the deep end last year. He pulled the (originally apache 2) source offline, then started threatening to sue people for hosting alternative versions, including them in other IDEs, etc. Genuine lunatic.
Out of an abundance of precaution, I've taken the following action on my fork:
1. I have the VS Code team auditing it as we speak, and I've given them full permission to immediately pull it from the marketplace & force uninstall it from users if they find ANYTHING malicious.
2. I have audited the code base thoroughly (nothing seemed malicious)
3. I have removed ALL code related to changelogs, analytics, Open Collective and html rendering.
The only thing that seemed slightly concerning was the html + sanity loader for changelogs, so I gutted it entirely. Two PRs removed almost all the deps and over 7,000loc (mostly package-lock)
To me it seems ridiculous, that a theme could even accumulate such things as analytics and even lots of dependencies. A theme is usually something self-contained. And even more ridiculous, that anyone can, as you write, "force uninstall" anything from my machine. So glad I am not a VS Code user. It seems all the typical corporate BS is happening with its marketplace and plugins.
Curiously, someone on reddit noticed suspicious changes in this extension 7 months ago [1]. Obfuscation in open source is usually an extreme red flag. Microsoft really needs to rethink their security model for vs code extensions. It has simply become way too profitable to target given whatever they are doing against it. For every dev they ban 10 will come with new malicious extensions.
VS Code is maybe the best product Microsoft has ever released, largely because the extension market. If Microsoft polices the marketplace more, you can probably expect VS Code quality to degrade.
Here's my argument: More scrutiny of the marketplace will lead to less extensions overall (the scrutiny process will reduce the number of extensions overall as barrier to entry will be increased). Less extensions available will create an incentive for Microsoft to add features to VS Code directly. The more features MS adds, the more bloated VS Code will become.
So then, more security auditing in the extensions marketplace will lead to a more bloated VS Code.
All that said, it would be nice if there were better security controls in the extensions marketplace, I just don't trust Microsoft to do anything in a way that actually improves their products for the people who use them.
You do not have to police everything, copy what Mozilla is doing: pass the top X extensions through manual audits (including looking at code diffs on every update) and mark them as trusted. Maybe also add a giant warning "this extension may steal your stuff" when installing everything else.
It took a while, but Microsoft got it pretty much right with Windows Defender. It quietly made all other active scanners obsolete. It's just a question of how much effort they're willing to spend on a free product's infrastructure.
Reading the commentary, this guy seems unhinged. He thinks he owns literal hex codes
he sucks at tech and has driven away everyone good at it. I don't use his software, but I hope he gets out of this episode soon (and learns he didn't invent material!)
Someone else described him as a lunatic. But, this is a security issue, and you shouldn't assume that someone who is successfully putting malicious code into developers' IDEs around the world is unhinged or a lunatic, but rather cunning and deceptive (or a front for an intelligence agency). It's not paranoid to have such suspicions about someone who is getting malicious code into developers' tools.
The original author seemed to talk a lot about funding development/maintenance, so I got curious about what the hell needs to be maintained. I cloned the https://github.com/t3dotgg/vsc-material-but-i-wont-sue-you repo and had a look. Here's a LoC summary:
Among those, 622 lines of TS are hex color definitions for variants in scripts/generator/settings/specific. Most of the rest seems pretty boilerplatey, e.g. look at the 599 lines in scripts/generator/color-set.ts.
So the question remains: what the hell is there to maintain (that takes more than a couple minutes every $godknowshowlong)? I've published and maintained waaaaay more substantial open source projects for years without expectation of any financial contribution.
There's nothing wrong with building proprietary software of a couple of thousand lines of code, including themes. And people should be able to ask for money in exchange for their work.
What's wrong is the bait and switch, as these projects end up being popular because of their FOSS nature.
it's a problem. As soon as it became easy to ask for money via Patreon or githib sponsorship, etc... tons of people are going to try to get some for minimal effort. It's just the nature of the beast.
Readit News
A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us. Our security researchers at Microsoft confirmed this claims and found additional suspicious code.
We banned the publisher from the VS Marketplace and removed all of their extensions and uninstalled from all VS Code instances that have this extension running. For clarity - the removal had nothing to do about copyright/licenses, only about potential malicious intent.
Expect an announcement here with more details soon https://github.com/microsoft/vsmarketplace/
As a reminder, the VS Marketplace continuously invests in security. And more about extension runtime trust can be found in this article https://code.visualstudio.com/docs/editor/extension-runtime-...
Thank you!
I had to manually delete the extension's folder in %USERPROFILE%\.vscode\extensions and delete the entry from the json (%USERPROFILE%\.vscode\extensions\extensions.json).
VSCode 1.97.2, commit e54c774e0add60467559eb0d1e229c6452cf8447
> A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us.
> As a reminder, the VS Marketplace continuously invests in security
If you’re relying on the community to alert you to the issues in the marketplace, perhaps you’re not investing enough in auditing popular extensions yourself?
I would also suggest that the trust model for VSCode is fundamentally broken - you’re running arbitrary third party code on client machines without any form of sandboxing. This is a level of security you would not deploy into Azure, so why is “run arbitrary 3p code on someone else’s machine” appropriate for VSCode?
While I appreciate the work that the VSCode team does and I use it, the lack of any form of sandboxing has always bothered me.
Mitigations like running in a VM might protect your dev workstation. But not code you put into production that relies on third parties.
Reminder that the Open-VSX extension registry exists: https://open-vsx.org
Idk if they removed the malicious theme (or if they have it at all), but if MS isn't doing anything beyond just responding to user reports, you might as well switch to an open registry that probably does the same level of security work, and avoid giving them yet another monopoly.
I think that's sort of unfair. Of course MS should be relying on the community! That's arguably the best single practice for detecting these kinds of attacks in open source code. Objectively it works rather better even than walled garden environments like the iOS/Android apps stores (which have to be paired with extensive app-level sandboxing and permissions management, something that editor extensions can't use by definition).
The reference case for best practice here is actually the big Linux distros. Red Hat and Canonical and Debian have a long, long track record of shipping secure software. And they did it not on the back of extensive in-house auditing but by relying on the broader community to pre-validate a list of valuable/useful/secure/recommended software which they can then "package".
MS's flaw here, which is shared by NPM and PyPI et. al., is that they want to be a package repository without embracing that kind of upstream community validation. Software authors can walk right in and start distributing junk even though no one's ever heard of them. That has to stop. We need to get back to "we only distribute stuff other people are already using".
More and more, I am starting to think I need to run my development environment (for both work and personal projects) in a VM.
I am on MacOS, so UTM or Parallels would work pretty well I think. Sadly, I think my work explicitly forbids us from running VMs or accessing our services from them.
Sure. As a general rule, you get what you pay for.
https://marketplace.visualstudio.com/items?itemName=t3dotgg....
https://youtu.be/3wz7YF2as-c
Hi Isidor, excited for this! At Open VSX, we'd love to take a look and potentially flag the extension as malicious on our side as well. Are you aware of the version range that the malicious code was included in? I'm asking because https://open-vsx.org does not have any version published since the extension went closed-source.
I downloaded the file, and unzipped it, but on a cursory glance I only see obfuscated code nothing malicious.
[0]: !!!WARNING MAY BE MALICIOUS!!! https://marketplace.visualstudio.com/_apis/public/gallery/pu...
The publisher account for Material Theme and Material Theme Icons (Equinusocio) was mistakenly flagged and has now been restored. In the interest of safety, we moved fast and we messed up. We removed these themes because they fired off multiple malware detection indicators inside Microsoft, and our investigation came to the wrong conclusion. We care deeply about the security of the VS Code ecosystem, and acted quickly to protect our users.
I understand that the "Equinusocio" extensions author's frustration and intense reaction, and we hear you. It's bad but sometimes things like this happen. We do our best - we're humans, and we hope to move on from this We will clarify our policy on obfuscated code and we will update our scanners and investigation process to reduce the likelihood of another event like this. These extensions are safe and have been restored for the VS Code community to enjoy.
LINKS: Material Theme https://marketplace.visualstudio.com/items?itemName=Equinuso... Material Theme Icons https://marketplace.visualstudio.com/items?itemName=Equinuso...
Again, we apologize that the author got caught up in the blast radius and we look forward to their future themes and extensions. We've corresponded with him to make these amends and thanked him for his patience.
Scott Hanselman and the Visual Studio Code Marketplace Team - @shanselman
- build an open-source thing
- wait till thousands or millions of people are using it
- change the license and close down the source
- implement malicious code
- push an update
- profit! you now have your malware running on millions of systems
I did a thorough combing of the code base when I forked. Just did another audit and still not seeing anything suspicious. Gutting all of the opencollective and changelog code to be 1000% sure.
Deleted Comment
The extension file is still available to download directly from MS.[0] (Which, why if you pull it from users are you still allowing downloads first of all.)
I downloaded the file, and unzipped it. On a cursory glance I see obfuscated code but zero "red flag" level code, has anyone seen the malicious code claimed?
[0]: !!!WARNING CLAIMED TO BE MALICIOUS!!! https://marketplace.visualstudio.com/_apis/public/gallery/pu...
We do not plan to add a permission model in the next 6 months.
The only sane way to contain the blast radius is to run is to run code-server in a container (or in a VM) and use it through a browser tab.
Luckily, the UI works perfectly, hotkeys and everything. They did an awesome work there.
Anyway, thank you for the update.
https://pastebin.com/H5QjS4Bt
Deleted Comment
https://www.wired.com/story/gravy-location-data-app-leak-rtb...
[0] https://en.wikipedia.org/wiki/Fanny#In_slang
Deleted Comment
Deleted Comment
Dead Comment
Dead Comment
The maintainer went off the deep end last year. He pulled the (originally apache 2) source offline, then started threatening to sue people for hosting alternative versions, including them in other IDEs, etc. Genuine lunatic.
Out of an abundance of precaution, I've taken the following action on my fork:
1. I have the VS Code team auditing it as we speak, and I've given them full permission to immediately pull it from the marketplace & force uninstall it from users if they find ANYTHING malicious.
2. I have audited the code base thoroughly (nothing seemed malicious)
3. I have removed ALL code related to changelogs, analytics, Open Collective and html rendering.
The only thing that seemed slightly concerning was the html + sanity loader for changelogs, so I gutted it entirely. Two PRs removed almost all the deps and over 7,000loc (mostly package-lock)
Repo is here if anyone else would like to audit https://github.com/t3dotgg/vsc-material-but-i-wont-sue-you
however, I found this from the malware creator's website itself: https://framerusercontent.com/images/G17CYe9tTL2GP1Rw4mUI8YC...
Deleted Comment
Dead Comment
[1] https://www.reddit.com/r/vscode/comments/1eq40o2/has_the_mat...
VS Code is maybe the best product Microsoft has ever released, largely because the extension market. If Microsoft polices the marketplace more, you can probably expect VS Code quality to degrade.
Here's my argument: More scrutiny of the marketplace will lead to less extensions overall (the scrutiny process will reduce the number of extensions overall as barrier to entry will be increased). Less extensions available will create an incentive for Microsoft to add features to VS Code directly. The more features MS adds, the more bloated VS Code will become.
So then, more security auditing in the extensions marketplace will lead to a more bloated VS Code.
All that said, it would be nice if there were better security controls in the extensions marketplace, I just don't trust Microsoft to do anything in a way that actually improves their products for the people who use them.
Deleted Comment
he sucks at tech and has driven away everyone good at it. I don't use his software, but I hope he gets out of this episode soon (and learns he didn't invent material!)
Pantone would like a word.
These aren't mutually exclusive.
https://marketplace.visualstudio.com/items?itemName=t3dotgg....
So the question remains: what the hell is there to maintain (that takes more than a couple minutes every $godknowshowlong)? I've published and maintained waaaaay more substantial open source projects for years without expectation of any financial contribution.
What's wrong is the bait and switch, as these projects end up being popular because of their FOSS nature.
just did a pass and removed everything that was not necessary - it's even less code now lmao
At least that one wasn't literally just colours.
Dead Comment
Found the obfuscated code here https://web.archive.org/web/20250226020241/https://github.co...