Malicious VSCode extensions with more than 45k installs

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.)<p>“…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. And this makes it hard to hide malware.” <a href="https:&#x2F;&#x2F;borretti.me&#x2F;article&#x2F;how-capabilities-work-austral" rel="nofollow">https:&#x2F;&#x2F;borretti.me&#x2F;article&#x2F;how-capabilities-work-austral</a><p>The original quote talks about a leftpad dependency but it’s a drop-in substitution to apply it here, too. It’s right there in the screenshot:<p><pre><code> const https = require(‘http’) const os = require(‘os’) </code></pre> Both of those calls ought to error out with “Error: Network capability not provided” and “Error: filesystem capability not provided”, respectively.

Actually malicious extension only had 250 downloads, 45k installs extension was sending telemetry only. It’s a very misleading title collapsing two separate incidents into one for the sake of dramatization.<p>This article also highlighted that automated tools used by VS team are pretty good at catching most of similar issues.

Article disingenuously wraps a couple extensions that seem to be “actually” malicious (secret stealing), with one that has a lot of installs and is “HN-malicious” (collects telemetry) for a striking headline.<p>That said, malicious code in VS Code extensions is a problem. I wonder if a GPT could be helpful here. The existing internal systems for detecting malicious code seem lacking.

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.)<p>However, the way things are going, news of these vulnerabilities &#x2F; incidents will be used to push through the Codespaces (IDE on the cloud) among enterprises -- and many companies will fall for it.<p>I guess software engineers and technical experts cannot be trusted anymore to keep their machines safe. :-&#x2F;

This feature request has been sitting around since 2018:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;52116">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;vscode&#x2F;issues&#x2F;52116</a><p>It advocates for treating VSCode extension permissioning like browser extension permissioning.<p>Of course, it&#x27;s not a panacea, but it would be lovely to have.<p>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.

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

I work in this space and see these types of &quot;hit articles&quot; so often.<p>These &quot;security researchers&#x2F;products&quot; aren&#x27;t doing anything more than spreading FUD and trying to sell their own products. Most of the FUD they spread is so widely misunderstood and positioned as if X thousands of machines&#x2F;developers were &quot;affected&quot;. The reality is much different.<p>In the name of being a good security citizen, please just report these extensions so action can be taken and less copy cats occur. Stop writing about these non-events. The reality of each registry is that there will always be bad extensions&#x2F;packages&#x2F;etc. The stewards of each registry work very hard to keep them safe. These types of articles make their lives harder, not easier.

I&#x27;ll take the opportunity to self plug: I&#x27;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<p>You&#x27;re welcome to sign up for early access at <a href="https:&#x2F;&#x2F;coderguard.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;coderguard.io&#x2F;</a><p>As I&#x27;m currently mainly looking for user feedback

As I understand, VSCode extensions can run arbitrary shell commands and Microsoft didn&#x27;t add any security measures (e.g. asking a user for confirmation). In this case it is only a matter of time, motivation and perseverance until all users who use extensions will get a back door.<p>Of course this applies not only to VS Code, but to any other software which allows to install third-party extensions like browsers, Gimp, Inkscape, DAWs like Ableton Live, etc. Their developers do not care about security and do not take measures to protect against malicious extensions.

There&#x27;s some capabilities-based security talk going on here, but the current state of the art in JavaScript makes absolutely no sense to me. It&#x27;s nonsensical on its face. Right now, you grant caps through Deno to the whole executable script--so dependencies left and right that don&#x27;t need caps get them.<p>So, what&#x27;s the point? It&#x27;s literally worthless. It does nothing to stop capabilities abuse.<p>The same thing could have happened here with Visual Studio Code. The language nor its popular runtimes are simply not designed for this behavior.<p>As far as I know Node.js still doesn&#x27;t have capabilities functionality, which doesn&#x27;t matter, because how broken Deno&#x27;s is means they&#x27;re practically on the same footing.

If Dracula Dark&#x27;s telemetry is malicious, VSCode itself also malicious XDDDDD

&gt; These continued findings highlight the need to verify every open-source component, not just assume it will be ok. We have included details regarding our specific findings below.<p>So, how they suggest we do this with extensions for Visual Studio Code? The editor, as far as I know, doesn&#x27;t contain any utilities for inspecting the actual source code of the installed plugin before installing, and instead you would have to use some 3rd party thing for downloading the zip file, then manually inspect the contents, before manually installing from the zip archive.<p>With a subtitle of &quot;Securing the cloud&quot;, it&#x27;s hard to see how they are securing anything here, besides removing three extensions that may or may not be malicious. They&#x27;re not actually providing any solution, even though they end with plugging their CloudGuard Spectral product that wouldn&#x27;t even help in this particular case...

&gt; This fact highlights again the open-source components risk; no one guarantees that the open sources we use are benign, and it’s our responsibility to verify them.<p>It&#x27;s odd to call this &quot;the open-source components risk&quot; when the exact same things are true for closed-source...

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&#x27;t miss anything important.

thats why we need wasi&#x2F;wasm bashed sandboxed plugins scoped bashed on capability it needs.<p>i think lapce supports wasi plugin but overall ux is not there yet when i last tried.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;lapce&#x2F;lapce">https:&#x2F;&#x2F;github.com&#x2F;lapce&#x2F;lapce</a>

Some people have argued that we should work inside expendable and tightly restricted VMs when doing anything that involves fetching packages from a repository using a package manager. I used to feel that was quite an extreme position but it does make sense because the risk we&#x27;re discussing is really a consequence of two systemic vulnerabilities. Mainstream desktop operating systems have weak security models that aren&#x27;t fit for purpose in our modern online-first world. And software development has evolved this strange philosophy that fetching someone else&#x27;s code for every tiny thing is a good idea and code in someone else&#x27;s repo is better than anything we could write ourselves. Those are both terrible ideas but neither is going to change quickly so maybe the sandbox advocates aren&#x27;t so extreme after all?<p>Also did anyone else notice the timeline at the end of the article where it took <i>10 days</i> to remove these packages from the repo? I could understand some hesitation if a package has something like debatable telemetry but surely behaviour like obfuscated code should result in an immediate block by default?

They only found these malwares because the malware part was at the top level. Who knows how many are there that hide this logic in an npm dependency.

I have been leery of VSCode for this reason. The bare product isn’t very special, so you have to download extensions to get the functionality you need. However, there is nothing keeping the extension from communicating. Suddenly, you get malicious extensions that leak data.<p>It’s not just malicious extension authors. Compromised developers of good extensions are just as much, if not bigger, of a risk.

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&#x27;s bubblewrap and docker). As a result everything is cleaner and vscode is isolated from the host.<p>Access to local folders on the host (though rare) is approved on a needs basis.

I think this is missing advice for staying safe. It mostly just pushes their product and says<p>&gt; it’s our responsibility to verify<p>I&#x27;d recommend checking of your extensions are from a verified publisher. See <a href="https:&#x2F;&#x2F;code.visualstudio.com&#x2F;api&#x2F;working-with-extensions&#x2F;publishing-extension#verify-a-publisher" rel="nofollow">https:&#x2F;&#x2F;code.visualstudio.com&#x2F;api&#x2F;working-with-extensions&#x2F;pu...</a>

I always find this question interesting.<p>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 wonder if there&#x27;s a marketplace or active efforts for bad actors to buy popular vscode extensions so that they can inject malware into formerly trusted extensions? If you have a popular vscode extension do you get people reaching out to you to offer to buy it? I know this was fairly commonplace with browser addons.

let this be a reminder that little snitch has existed for a long time and we all should be using it in prompt-for-everything mode.<p>there are multiple implementations for macos. there are multiple implementations for linux. run, don’t walk.<p>yes, there are tradeoffs. you may even changes your web browsing habits to avoid a tirade of prompts from some random chum bucket. it’s all worth it when one of your eyebrows goes up after some process that tries to make a dns request it doesn’t have any business making. then you hit deny. then you investigate.<p>now all we need is little snitch for filesystems. maybe we can build it on encrypted fuse mounts.

Hard to gauge the actual impact without privileged access, as I would guess authors of these extensions would pump the downloads to get higher in rankings, raking in higher numbers of actual victims.

Calling analytics telemetry malicious is exaggeration. But the telemetry should be an opt-in, or at least, a visible opt-out.

Hardly a newsworthy article IMO.

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.<p>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&#x27;s doing. Now, whether you define telemetry as malicious or not may shape how you feel, but let&#x27;s be honest, there&#x27;s a world of difference between sending your OS versions to a telemetry server and injecting obfuscated code.