▲ 317 points
back
186 comments
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. And this makes it hard to hide malware.” https://borretti.me/article/how-capabilities-work-austral
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:
const https = require(‘http’)
const os = require(‘os’)
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.
I want that feature too, but in reality, many non-trivial extensions require the execution of binaries such as language servers. Applying capability models to these executables will require OS support or containerization, but the overhead for memory and disk will be huge. In fact, even an extension to auto-complete paths in .gitignore files requires running a language server written in Rust [1], and it has the real benefit of supporting multiple editors with ease. If the "prettiest java" or "python-vscode" extensions in the article insisted on needing full permissions for Java or Python execution, I believe users would be convinced and end up installing them.
[1] https://github.com/quentinguidee/gitignore-ultimate-vscode
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.
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.
Packj [1] flags malicious/risky NPM/PyPI/RubyGems packages by carrying out static analysis and looking for capabilities/permissions (diff from runtime permission enforcement). Supporting VSCode/browser extensions is on our roadmap.
Disclaimer: I'm the lead developer.
In the context of an editor, this can be bypassed by writing this kind of code to the project, which will be run when the developer runs the project, runs tests, or in some languages even when the project is compiled.
A theme probably doesn't need access to the project files, but many extensions do. This is much harder to solve than in e.g. Android.
This is exactly what deno does: https://deno.com/manual@v1.33.4/basics/permissions
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.
This article also highlighted that automated tools used by VS team are pretty good at catching most of similar issues.
Tracking your host name is not telemetry, it's definitely spyware.
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.
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.
"HN-malicious"
Hehe. We could probably come up with a dozen similar HN specific adjectives.
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 software engineers and technical experts cannot be trusted anymore to keep their machines safe. :-/
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 resolve correctly (this is my from memory summary)
>I guess software engineers and technical experts cannot be trusted anymore to keep their machines safe. :-/
When SEs could be trusted?
We run so much 3rd party code that it would be insane to expect SEs to verify it.
Security industry is also heavy of bullshit
Instead of performing reviews they run some "scanners" and fill checkboxes
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.
> I guess software engineers and technical experts cannot be trusted anymore to keep their machines safe.
Were they ever? It's a big set of folks, and while some of them were and are competent an even larger subset isn't.
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 added to the subset but then it's available for everyone.
All it takes is one tired/careless/unlucky dev or it engineer to get their machine owned, at minimum resulting in an extensive and tiring incident response and forensic verification to confirm nothing else happened, bearing in mind once the attackers get a foothold they'll try to blend in.
> 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.
This 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.
2 out of the 3 examples do not have more than 45k installs. The one example that did "had a simple PII stealer code" but was actually just sending telemetry.
The point of the article is probably valid, but the article itself seems to be dishonest.
I noticed that too, right from the headline "Malicious Extensions with more than 45,000 Installs" with a screenshot showing "278 installs".
Exaggerate much?
Does the 45k installs mean for a specific extension or just that 45k installs in total of all extensions?
I work in this space and see these types of "hit articles" so often.
These "security researchers/products" aren'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/developers were "affected". The reality is much different.
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/packages/etc. The stewards of each registry work very hard to keep them safe. These types of articles make their lives harder, not easier.
> The stewards of each registry work very hard to keep them safe.
What kinds of things do they do? Any idea how this slipped through? Do you know what the review process entails before a plugin is made available for download?
I'll take the opportunity to self plug:
I'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
You're welcome to sign up for early access at https://coderguard.io/
As I'm currently mainly looking for user feedback
Looks interesting, I used to work on the vscode team, lmk if there’s anything I might help with.
As I understand, VSCode extensions can run arbitrary shell commands and Microsoft didn'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.
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.
Why should we? Repos like ELPA, NonGNU and CPAN are trusted enough.
There'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's nonsensical on its face. Right now, you grant caps through Deno to the whole executable script--so dependencies left and right that don't need caps get them.
So, what's the point? It's literally worthless. It does nothing to stop capabilities abuse.
The same thing could have happened here with Visual Studio Code. The language nor its popular runtimes are simply not designed for this behavior.
As far as I know Node.js still doesn't have capabilities functionality, which doesn't matter, because how broken Deno's is means they're practically on the same footing.
If Dracula Dark's telemetry is malicious, VSCode itself also malicious XDDDDD
> 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.
So, how they suggest we do this with extensions for Visual Studio Code? The editor, as far as I know, doesn'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.
With a subtitle of "Securing the cloud", it's hard to see how they are securing anything here, besides removing three extensions that may or may not be malicious. They're not actually providing any solution, even though they end with plugging their CloudGuard Spectral product that wouldn't even help in this particular case...
> 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.
It's odd to call this "the open-source components risk" 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't miss anything important.
thats why we need wasi/wasm bashed sandboxed plugins scoped bashed on capability it needs.
i think lapce supports wasi plugin but overall ux is not there yet when i last tried.
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're discussing is really a consequence of two systemic vulnerabilities. Mainstream desktop operating systems have weak security models that aren't fit for purpose in our modern online-first world. And software development has evolved this strange philosophy that fetching someone else's code for every tiny thing is a good idea and code in someone else'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't so extreme after all?
Also did anyone else notice the timeline at the end of the article where it took 10 days 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.
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'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.
I think this is missing advice for staying safe. It mostly just pushes their product and says
> it’s our responsibility to verify
I'd recommend checking of your extensions are from a verified publisher. See https://code.visualstudio.com/api/working-with-extensions/pu...
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 wonder if there'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.
there are multiple implementations for macos. there are multiple implementations for linux. run, don’t walk.
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.
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.
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.