17 ms·

Malicious VSCode extensions with more than 45k installs

317 points by chha 3y ago

Segel 3y ago
If Dracula Dark's telemetry is malicious, VSCode itself also malicious XDDDDD
factorialboy 3y ago
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. :-/
- qup 3y ago
  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.
  - throwaway290 3y ago
    I always give source code a glance, unless it's by a sufficiently prominent and reputable maintainer.
    - maccard 3y ago
      Do you check _their_ dependencies though? And do you check every file?
      - throwaway290 3y ago
        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.
        qup 3y ago
        Have you ever caught anything?
        throwaway290 3y ago
        No, that would be a different story:) ended up not using dozens of plugins and libs stuff after a look at their dependencies and code though
      - anthk 3y ago
        Emacs has deps on libraries such as pdf-tools with mupdf and telega with tdlib, but these are installed from the OS repos so they are trustful.
      - Jorengarenar 3y ago
        Only handful of Vim plugins have dependencies and even then you need to install them explicitly
  - deleted 3y ago
    [deleted]
  - PhilipRoman 3y ago
    As a bare minimum security measure, when using plugins (all 9 of them), my Vim runs in a bubblewrap sandbox with only my project folder mounted as writable. Network and IPC access is completely disabled. It is secure enough to stop practically all non-targeted attacks. Generally I try to install plugins whose authors I know. And whenever I update them (once a year) I re-read the entire source code. Some small plugins I just integrate in vimrc directly. I hate to say this but Vim isn't the most secure editor, considering features like modelines which some environments enable by default and an aggressive plugin installing culture.
    - anthk 3y ago
      So it's Emacs, but we want features and not to be locked. Don't run propietary crap, trust Elisp repo like ELPA and NonGNU and you will be mostly safe.
      - rollcat 3y ago
        Isn't MELPA just serving the latest git master of whatever it happens to be at the time package-refresh-contents was called? With MELPA stable likewise just serving the latest tag? That doesn't spell trust.
        medo-bear 3y ago
        Using Emacs is not going to help you to avoid supply chain attacks per se. What it might do, however, is give you unparalleled power to inspect your environment - calls and source. If you run untrusted code you are exposed, and thats that. Development tools should assume that you, a programmer, know what you are programming. Emacs and lisp is focused on providing power, not security. These often do not go hand in hand.
        rollcat 3y ago
        > What it might do, however, is give you unparalleled power to inspect your environment [...] The "read the source" argument. It doesn't scale. I don't have 17 lifetimes to study a single release of every bit of software I run. I really do appreciate Emacs for the introspection capabilities, but it's not a solution to the trust chain issue.
- krageon 3y ago
  > 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.
  - mango7283 3y ago
    Too add salt to the wound often their machines have more rights/access too, making the impact that much more.
- mango7283 3y ago
  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.
- samwillis 3y ago
  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.
  - imoverclocked 3y ago
    Sure, but the business model for the entity providing that sucks. Practically infinite amounts of possible exploits and extremely finite resources to detect them. Either that or you are back to where you started with a web of trust.
    - Silhouette 3y ago
      I agree that would be a tough business model. Even for a relatively small package set like VS Code plugins there must be many thousands of releases to check every year and the potential market of paying customers for the tool is limited. Maybe it could work if some of the tech giants sponsored it? For the wider problem of depending on external packages and managers like pip or npm I don't see how anyone could realistically keep up with the scale of releases that would need to be checked. You would need far fewer packages from far fewer sources with far less frequent releases for this to be a viable strategy. That might be nicer for developers for other reasons as well but it's not the world we live in today.
      - samwillis 3y ago
        > Maybe it could work if some of the tech giants sponsored it its not about them sponsoring it, that frames it wrong. They news to use it, they have security budgets in the tens of millions, they will already be doing some auditing of their own. A vendor can provide that service to the wider market.
    - afiori 3y ago
- MrGilbert 3y ago
  > 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.
  - suddenclarity 3y ago
    Are we more cautious? We might not fall for the old scam of extension bars in the browser and approving spam notifications but I'm sure plenty of people would blindly follow a tutorial to run commands in the terminal and install dependencies to run code. The most recent example was probably Win 11 replacing the status bar and people recommending all kinds of anonymous software on GitHub. It's open source and works so it must be alright.
    - Silhouette 3y ago
      Plenty of popular developer-friendly tools have installation instructions that involve sudo, curl and piping to sh. That says everything we need to know. But if it didn't then the way many developers will casually install packages from untrusted third parties when the installation scripts themselves could do almost anything says the rest. In addition developer PCs often have more privileges than a typical office worker. That's legitimately useful for our work but also means compromising a developer machine is a bigger risk. We're a nightmare for any organisation that wants proper IT security.
- hardware2win 3y ago
  >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
- moonchrome 3y ago
  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)
  - discreteevent 3y ago
    If you apply principle of least privilege to developers then ideally you should have a whitelist of every software package that they need to use. What happens then when a productive developer, instead of developing from scratch, searches for a solution to some problem and discovers that there is already a module that may solve it? Do they go to some central committe to get approval to add it to the whitelist? What are their criteria? How long will it take them to approve it? Suppose it takes a couple of days. Then the developer tries the module. Discovers immediately that the module doesn't solve the problem. That's two days wasted for nothing. Suppose some module that has dependencies on a huge list of other modules. How long will it take now? I'm not saying polp isn't valid. But is it practical?
    - moonchrome 3y ago
      > Do they go to some central committe to get approval to add it to the whitelist? What are their criteria? How long will it take them to approve it? Yes, depends on the org, depends on the org. Introducing third party dependencies should not be a single person decision.
  - megous 3y ago
    Oh, yeah. That's how I have to treat large orgs as a contractor. :) And trouble start almost immediately, because they apply PoLP only to you... First thing with a new client is usually some form of a VPN access. Even with open protocols, it's challenging to secure a VPN access. Eg. by default running openvpn with a random config provided by a third party allows the third party to push any network setup they want remotely. There's no whitelist, etc. It takes quite a bit of effort to run openvpn as unprivileged user and make it do all network setup via a trusted setuid helper tool that can do whitelisting of allowed network configurations. And oftentimes VPN has to be some closed source garbage. Management daemons for these require high privileges and take remote commands on how to reconfigure the network and god knows what else. They also can't deal with any non-basic networking setup. The first such VPN solution I had to briefly deal with (before telling the client that we'll want something secure for both sides and it's going to be a fixed wireguard config), was some Linux binary blob that I checked in ghidra before running, and one of the first things it did was scan the system for USB devices, and it had other hidden (to the end user, probably not to the buyer) remote management functionality absolutely irrelevant to a VPN software. Devs need to apply PoLP also to the clients. Otherwise it's quite easy to accidentally route networks of multiple different clients together via a dev's machine.
3np 3y ago
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.
streakfix 3y ago
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.
- croes 3y ago
  Reminds me of https://david-gilbertson.medium.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://david-gilbertson.medium.com/im-harvesting-credit-car...
- shzhdbi09gv8ioi 3y ago
  Now what if there only was a way to detect apps doing suspicious network requests... /s
explaininjs 3y ago
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.
- skc 3y ago
  "HN-malicious" Hehe. We could probably come up with a dozen similar HN specific adjectives.
  - voynich 3y ago
    Lol. MS Notepad is HN-bloated.
    - yjftsjthsd-h 3y ago
      I would argue that Notepad was one of the few apps that wasn't HN-bloated. Although, I kind of think I head that they rewrote it, so it probably is now...
  - lioeters 3y ago
    HN-incompatible: Any website that hijacks the scroll bar or the back button of the browser..
  - paulddraper 3y ago
    "HN-stupid" Anything known to be wrong with 20/20 hindsight.
maccard 3y ago
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.
- animuchan 3y ago
  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.
  - tjoff 3y ago
    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.
    - capableweb 3y ago
      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.
      - explaininjs 3y ago
        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.
fwlr 3y ago
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 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’) Both of those calls ought to error out with “Error: Network capability not provided” and “Error: filesystem capability not provided”, respectively.
- ryanjshaw 3y ago
  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.
- Gigachad 3y ago
  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.
  - carlmr 3y ago
    I'd say VSCode is a bit different in who it's aimed at. Only because it doesn't work for a consumer product doesn't mean this wouldn't work for VSCode. Also it might be good to be more specific. E.g. don't ask for all permissions at once, instead if the app starts talking to telemetry.endpoint.com it has to ask for these specific permissions at that point. Then the user can see, hey this is requesting access to this particular server, that seems fishy, let's not proceed.
    - 3y ago
Silhouette 3y ago
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?
- anthk 3y ago
  >Mainstream desktop operating systems have weak security models that aren't fit for purpose in our modern online-first world Stop using propietary software first, then we will discuss your "security" rants. Perl users have been using CPAN since forever, so did LaTeX users with CTAN. Ditto with Emacs users with ELPA and NonGNU. No issues with addons.
  - Silhouette 3y ago
    This has little to do with being open or proprietary. CPAN is analogous to repositories we use with pip or npm today and most of what is involved is not proprietary on any of those platforms. The relevant differences are cultural and technical. I don't think invoking CTAN as an example is very convincing. It's well known that there are only seven people in the universe who can actually program TeX and they probably have little interest in trying to infect each other with malware.
dncornholio 3y ago
Hardly a newsworthy article IMO.
elashri 3y ago
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.
- zemnmez 3y ago
  I think this is what WhiteSource does. (it's also apparently called Mend now)
  - capableweb 3y ago
    Not only are the products confusing (which one does what parent mentioned?) but that pricing is out of reach for so many I'm wondering if the company is actually real or not? Cheapest plan starts at 1333 USD per month!
    - dist-epoch 3y ago
      If you are a big corp a security leak costs you 10 mil USD, it might make sense to pay. Instead of paying $50k for a one time security audit, you get a part of it in the form of a subscription.
codedokode 3y ago
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.
- explaininjs 3y ago
  Indeed. Professional woodworking equipment can also cut you, but that’s a risk we accept as we know their developers also care more about providing a tool that works and can be used responsibly by trained professionals. Yes we could insist everyone only hands us straight jackets in padded rooms, but I’m not sure that’d be a good thing.
  - fwlr 3y ago
    For over 20 years now, professional woodworkers have had SawStops, devices that literally use an explosive charge to ram a block of aluminum into the blade of a table saw when it detects that the blade is touching something that might be a human body part. These are $50+ devices that destroy themselves on use (and often destroy the $50+ blade they’re used on), they have a high false positive rate, and yet they’re still in heavy use and very popular with professional woodworkers. Table saws also have riving knives and sleds with clamps, both to prevent kickback. All of this on top of constantly educating woodworkers to be responsible and use push blocks instead of their hands, to boot. All of these safety features exist on table saws because we did educate woodworkers on how to be responsible, and we still saw that the average table saw will cause more than one injury in its lifetime. I’m actually really glad you brought up woodworking because table saws are a perfect example of how we saw “this is risky, be responsible” was inadequate.
    - robertlagrant 3y ago
      I remember as a kid seeing the Tomorrow's World episode where the chap demonstrated it to probably Philippa Forrester and Peter Snow. It looked like magic. What a great idea.
capableweb 3y ago
> 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...
Timber-6539 3y ago
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.
logdap 3y ago
[dead]
Mizoguchi 3y ago
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.
jawns 3y ago
This feature request has been sitting around since 2018: https://github.com/microsoft/vscode/issues/52116 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.
taw28 3y ago
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.
- peoplefromibiza 3y ago
  replace VSCode with any other code editor and it will still work. Vim, Emacs, Sublime are all examples of bare products that aren't very special unless you add extensions that could potentially leak data and run arbitrary commands. the fact that only a couple extensions have been found leaking some data involving only a few thousands installs, it's honestly a very good record if you ask me.
- shzhdbi09gv8ioi 3y ago
  > I have been leery of VSCode for this reason. > It’s not just malicious extension authors. Compromised developers of good extensions are just as much, if not bigger, of a risk. If this is your reason to avoid VSCode, then you should probably start avoiding basically all other code, too. It is after all written by developers, who can and has been compromised. All over the supply chain. Over and over again. And so on. But yea, hate on VSCode will you.
itsamy 3y ago
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/ https://coderguard.io/ As I'm currently mainly looking for user feedback
- jakear 3y ago
  Looks interesting, I used to work on the vscode team, lmk if there’s anything I might help with.
born-jre 3y ago
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. https://github.com/lapce/lapce https://github.com/lapce/lapce
thenerdhead 3y ago
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.
- criddell 3y ago
  > 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?
  - thenerdhead 3y ago
    Many things... They verify that submissions meet criteria. They scan for known malicious code/vulnerabilities. They work with security researchers to take appropriate action on reports. They enforce CoC and ToS policy to any that abuse it. They work with the community to address any unrest. They continuously monitor for suspicious activity. They respond to active security incidents. They work across many security working groups to stay current on best practices, latest standards, newest initiatives. As to your other questions, this isn't "slipping through". These registries act under a "trust but verify" model. It simply would not scale if they had to manually review all submissions akin to the app store(Zero trust). Most of these registries run on volunteers or small pizza teams. Every single registry has similar challenges. PyPi just last weekend had to halt user sign-ups and uploads due to these abuses.
8organicbits 3y ago
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/publishing-extension#verify-a-publisher https://code.visualstudio.com/api/working-with-extensions/pu...
bdcravens 3y ago
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.
- dylan604 3y ago
  Does the 45k installs mean for a specific extension or just that 45k installs in total of all extensions?
  - bdcravens 3y ago
    I read it as any extension with more than 45k installs. If it's 45k total, that's a very small percentage of all installs.
    - ezfe 3y ago
      Right, but the one with 45k installs wasn't malicious - sending os version telemetry isn't PII stealing
  - shzhdbi09gv8ioi 3y ago
    One of the extensions had 45213 installs, which is what the headline stated. But no matter how you count it, the rest of the extensions was far off 45k.
- shzhdbi09gv8ioi 3y ago
  I noticed that too, right from the headline "Malicious Extensions with more than 45,000 Installs" with a screenshot showing "278 installs". Exaggerate much?
andrewmcwatters 3y ago
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.
- danenania 3y ago
  I agree, but it's not a problem unique to javascript. I'm not aware of any popular language/runtime/package manager that goes beyond what Deno can do, however insufficient that is. It's quite a hard problem.
- explaininjs 3y ago
  The “right answer” afaik is to adopt the web permission model, which VSCode actually already supports. In addition to the Node extension host, there’s a WebWorker extension host which is much more secure (it’s the only host available on things like vscode.dev). Extensions need to opt into it unfortunately, but the code changes are not too bad in my experience.
- hombre_fatal 3y ago
  It’s a problem with security across computing in general, not just JS. For example, what are these languages and runtimes you have in mind that solve this issue with app plugins if VS Code were using them instead?
  - andrewmcwatters 3y ago
    In other languages, it's possible to set environments where code run from that environment have restricted access to explicitly defined globals. You can do this to create things like plugin systems, etc, where you know by specification you never want a context to have access to say, making HTTP requests.
ianzakalwe 3y ago
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.
- newaccount74 3y ago
  Tracking your host name is not telemetry, it's definitely spyware.
  - scotty79 3y ago
    Still, it's not nearly on the same level as exfiltrating secrets.
  - cywick 3y ago
    Exactly. Typically, exfiltrating this kind of information is only the first step. Once enough high value targets are caught in this net, the actual malware is deployed.
nathants 3y ago
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.
garganzol 3y ago
Calling analytics telemetry malicious is exaggeration. But the telemetry should be an opt-in, or at least, a visible opt-out.
- 8organicbits 3y ago
  Name/typo squatting is deceptive and malicious. The telemetry helps the attacker detect when a valuable target begins using the software, enabling a targeted supply-chain attack.
calibas 3y ago
> 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...
siegecraft 3y ago
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.

317 points by chha 3y ago

If Dracula Dark's telemetry is malicious, VSCode itself also malicious XDDDDD

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. :-/

qup 3y ago
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.
- throwaway290 3y ago
  I always give source code a glance, unless it's by a sufficiently prominent and reputable maintainer.
  - maccard 3y ago
    Do you check _their_ dependencies though? And do you check every file?
    - throwaway290 3y ago
      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.
      - qup 3y ago
        Have you ever caught anything?
        throwaway290 3y ago
        No, that would be a different story:) ended up not using dozens of plugins and libs stuff after a look at their dependencies and code though
    - anthk 3y ago
      Emacs has deps on libraries such as pdf-tools with mupdf and telega with tdlib, but these are installed from the OS repos so they are trustful.
    - Jorengarenar 3y ago
      Only handful of Vim plugins have dependencies and even then you need to install them explicitly
- deleted 3y ago
  [deleted]
- PhilipRoman 3y ago
  As a bare minimum security measure, when using plugins (all 9 of them), my Vim runs in a bubblewrap sandbox with only my project folder mounted as writable. Network and IPC access is completely disabled. It is secure enough to stop practically all non-targeted attacks. Generally I try to install plugins whose authors I know. And whenever I update them (once a year) I re-read the entire source code. Some small plugins I just integrate in vimrc directly. I hate to say this but Vim isn't the most secure editor, considering features like modelines which some environments enable by default and an aggressive plugin installing culture.
  - anthk 3y ago
    So it's Emacs, but we want features and not to be locked. Don't run propietary crap, trust Elisp repo like ELPA and NonGNU and you will be mostly safe.
    - rollcat 3y ago
      Isn't MELPA just serving the latest git master of whatever it happens to be at the time package-refresh-contents was called? With MELPA stable likewise just serving the latest tag? That doesn't spell trust.
      - medo-bear 3y ago
        Using Emacs is not going to help you to avoid supply chain attacks per se. What it might do, however, is give you unparalleled power to inspect your environment - calls and source. If you run untrusted code you are exposed, and thats that. Development tools should assume that you, a programmer, know what you are programming. Emacs and lisp is focused on providing power, not security. These often do not go hand in hand.
        rollcat 3y ago
        > What it might do, however, is give you unparalleled power to inspect your environment [...] The "read the source" argument. It doesn't scale. I don't have 17 lifetimes to study a single release of every bit of software I run. I really do appreciate Emacs for the introspection capabilities, but it's not a solution to the trust chain issue.
krageon 3y ago
> 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.
- mango7283 3y ago
  Too add salt to the wound often their machines have more rights/access too, making the impact that much more.
mango7283 3y ago
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.
samwillis 3y ago
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.
- imoverclocked 3y ago
  Sure, but the business model for the entity providing that sucks. Practically infinite amounts of possible exploits and extremely finite resources to detect them. Either that or you are back to where you started with a web of trust.
  - Silhouette 3y ago
    I agree that would be a tough business model. Even for a relatively small package set like VS Code plugins there must be many thousands of releases to check every year and the potential market of paying customers for the tool is limited. Maybe it could work if some of the tech giants sponsored it? For the wider problem of depending on external packages and managers like pip or npm I don't see how anyone could realistically keep up with the scale of releases that would need to be checked. You would need far fewer packages from far fewer sources with far less frequent releases for this to be a viable strategy. That might be nicer for developers for other reasons as well but it's not the world we live in today.
    - samwillis 3y ago
      > Maybe it could work if some of the tech giants sponsored it its not about them sponsoring it, that frames it wrong. They news to use it, they have security budgets in the tens of millions, they will already be doing some auditing of their own. A vendor can provide that service to the wider market.
  - afiori 3y ago
MrGilbert 3y ago
> 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.
- suddenclarity 3y ago
  Are we more cautious? We might not fall for the old scam of extension bars in the browser and approving spam notifications but I'm sure plenty of people would blindly follow a tutorial to run commands in the terminal and install dependencies to run code. The most recent example was probably Win 11 replacing the status bar and people recommending all kinds of anonymous software on GitHub. It's open source and works so it must be alright.
  - Silhouette 3y ago
    Plenty of popular developer-friendly tools have installation instructions that involve sudo, curl and piping to sh. That says everything we need to know. But if it didn't then the way many developers will casually install packages from untrusted third parties when the installation scripts themselves could do almost anything says the rest. In addition developer PCs often have more privileges than a typical office worker. That's legitimately useful for our work but also means compromising a developer machine is a bigger risk. We're a nightmare for any organisation that wants proper IT security.
hardware2win 3y ago
>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
moonchrome 3y ago
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)
- discreteevent 3y ago
  If you apply principle of least privilege to developers then ideally you should have a whitelist of every software package that they need to use. What happens then when a productive developer, instead of developing from scratch, searches for a solution to some problem and discovers that there is already a module that may solve it? Do they go to some central committe to get approval to add it to the whitelist? What are their criteria? How long will it take them to approve it? Suppose it takes a couple of days. Then the developer tries the module. Discovers immediately that the module doesn't solve the problem. That's two days wasted for nothing. Suppose some module that has dependencies on a huge list of other modules. How long will it take now? I'm not saying polp isn't valid. But is it practical?
  - moonchrome 3y ago
    > Do they go to some central committe to get approval to add it to the whitelist? What are their criteria? How long will it take them to approve it? Yes, depends on the org, depends on the org. Introducing third party dependencies should not be a single person decision.
- megous 3y ago
  Oh, yeah. That's how I have to treat large orgs as a contractor. :) And trouble start almost immediately, because they apply PoLP only to you... First thing with a new client is usually some form of a VPN access. Even with open protocols, it's challenging to secure a VPN access. Eg. by default running openvpn with a random config provided by a third party allows the third party to push any network setup they want remotely. There's no whitelist, etc. It takes quite a bit of effort to run openvpn as unprivileged user and make it do all network setup via a trusted setuid helper tool that can do whitelisting of allowed network configurations. And oftentimes VPN has to be some closed source garbage. Management daemons for these require high privileges and take remote commands on how to reconfigure the network and god knows what else. They also can't deal with any non-basic networking setup. The first such VPN solution I had to briefly deal with (before telling the client that we'll want something secure for both sides and it's going to be a fixed wireguard config), was some Linux binary blob that I checked in ghidra before running, and one of the first things it did was scan the system for USB devices, and it had other hidden (to the end user, probably not to the buyer) remote management functionality absolutely irrelevant to a VPN software. Devs need to apply PoLP also to the clients. Otherwise it's quite easy to accidentally route networks of multiple different clients together via a dev's machine.

3np 3y ago

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.

streakfix 3y ago

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.

croes 3y ago
Reminds me of https://david-gilbertson.medium.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://david-gilbertson.medium.com/im-harvesting-credit-car...
shzhdbi09gv8ioi 3y ago
Now what if there only was a way to detect apps doing suspicious network requests... /s

explaininjs 3y ago

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.

skc 3y ago
"HN-malicious" Hehe. We could probably come up with a dozen similar HN specific adjectives.
- voynich 3y ago
  Lol. MS Notepad is HN-bloated.
  - yjftsjthsd-h 3y ago
    I would argue that Notepad was one of the few apps that wasn't HN-bloated. Although, I kind of think I head that they rewrote it, so it probably is now...
- lioeters 3y ago
  HN-incompatible: Any website that hijacks the scroll bar or the back button of the browser..
- paulddraper 3y ago
  "HN-stupid" Anything known to be wrong with 20/20 hindsight.

maccard 3y ago

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.

animuchan 3y ago
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.
- tjoff 3y ago
  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.
  - capableweb 3y ago
    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.
    - explaininjs 3y ago
      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.

fwlr 3y ago

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 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’) Both of those calls ought to error out with “Error: Network capability not provided” and “Error: filesystem capability not provided”, respectively.

ryanjshaw 3y ago
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.
Gigachad 3y ago
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.
- carlmr 3y ago
  I'd say VSCode is a bit different in who it's aimed at. Only because it doesn't work for a consumer product doesn't mean this wouldn't work for VSCode. Also it might be good to be more specific. E.g. don't ask for all permissions at once, instead if the app starts talking to telemetry.endpoint.com it has to ask for these specific permissions at that point. Then the user can see, hey this is requesting access to this particular server, that seems fishy, let's not proceed.
  - 3y ago

Silhouette 3y ago

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?

anthk 3y ago
>Mainstream desktop operating systems have weak security models that aren't fit for purpose in our modern online-first world Stop using propietary software first, then we will discuss your "security" rants. Perl users have been using CPAN since forever, so did LaTeX users with CTAN. Ditto with Emacs users with ELPA and NonGNU. No issues with addons.
- Silhouette 3y ago
  This has little to do with being open or proprietary. CPAN is analogous to repositories we use with pip or npm today and most of what is involved is not proprietary on any of those platforms. The relevant differences are cultural and technical. I don't think invoking CTAN as an example is very convincing. It's well known that there are only seven people in the universe who can actually program TeX and they probably have little interest in trying to infect each other with malware.

dncornholio 3y ago

Hardly a newsworthy article IMO.

elashri 3y ago

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.

zemnmez 3y ago
I think this is what WhiteSource does. (it's also apparently called Mend now)
- capableweb 3y ago
  Not only are the products confusing (which one does what parent mentioned?) but that pricing is out of reach for so many I'm wondering if the company is actually real or not? Cheapest plan starts at 1333 USD per month!
  - dist-epoch 3y ago
    If you are a big corp a security leak costs you 10 mil USD, it might make sense to pay. Instead of paying $50k for a one time security audit, you get a part of it in the form of a subscription.

codedokode 3y ago

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.

explaininjs 3y ago
Indeed. Professional woodworking equipment can also cut you, but that’s a risk we accept as we know their developers also care more about providing a tool that works and can be used responsibly by trained professionals. Yes we could insist everyone only hands us straight jackets in padded rooms, but I’m not sure that’d be a good thing.
- fwlr 3y ago
  For over 20 years now, professional woodworkers have had SawStops, devices that literally use an explosive charge to ram a block of aluminum into the blade of a table saw when it detects that the blade is touching something that might be a human body part. These are $50+ devices that destroy themselves on use (and often destroy the $50+ blade they’re used on), they have a high false positive rate, and yet they’re still in heavy use and very popular with professional woodworkers. Table saws also have riving knives and sleds with clamps, both to prevent kickback. All of this on top of constantly educating woodworkers to be responsible and use push blocks instead of their hands, to boot. All of these safety features exist on table saws because we did educate woodworkers on how to be responsible, and we still saw that the average table saw will cause more than one injury in its lifetime. I’m actually really glad you brought up woodworking because table saws are a perfect example of how we saw “this is risky, be responsible” was inadequate.
  - robertlagrant 3y ago
    I remember as a kid seeing the Tomorrow's World episode where the chap demonstrated it to probably Philippa Forrester and Peter Snow. It looked like magic. What a great idea.

capableweb 3y ago

> 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...

Timber-6539 3y ago

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.

logdap 3y ago

[dead]

Mizoguchi 3y ago

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.

jawns 3y ago

This feature request has been sitting around since 2018: https://github.com/microsoft/vscode/issues/52116 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.

taw28 3y ago

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.

peoplefromibiza 3y ago
replace VSCode with any other code editor and it will still work. Vim, Emacs, Sublime are all examples of bare products that aren't very special unless you add extensions that could potentially leak data and run arbitrary commands. the fact that only a couple extensions have been found leaking some data involving only a few thousands installs, it's honestly a very good record if you ask me.
shzhdbi09gv8ioi 3y ago
> I have been leery of VSCode for this reason. > It’s not just malicious extension authors. Compromised developers of good extensions are just as much, if not bigger, of a risk. If this is your reason to avoid VSCode, then you should probably start avoiding basically all other code, too. It is after all written by developers, who can and has been compromised. All over the supply chain. Over and over again. And so on. But yea, hate on VSCode will you.

itsamy 3y ago

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/ https://coderguard.io/ As I'm currently mainly looking for user feedback

jakear 3y ago
Looks interesting, I used to work on the vscode team, lmk if there’s anything I might help with.

born-jre 3y ago

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. https://github.com/lapce/lapce https://github.com/lapce/lapce

thenerdhead 3y ago

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.

criddell 3y ago
> 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?
- thenerdhead 3y ago
  Many things... They verify that submissions meet criteria. They scan for known malicious code/vulnerabilities. They work with security researchers to take appropriate action on reports. They enforce CoC and ToS policy to any that abuse it. They work with the community to address any unrest. They continuously monitor for suspicious activity. They respond to active security incidents. They work across many security working groups to stay current on best practices, latest standards, newest initiatives. As to your other questions, this isn't "slipping through". These registries act under a "trust but verify" model. It simply would not scale if they had to manually review all submissions akin to the app store(Zero trust). Most of these registries run on volunteers or small pizza teams. Every single registry has similar challenges. PyPi just last weekend had to halt user sign-ups and uploads due to these abuses.

8organicbits 3y ago

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/publishing-extension#verify-a-publisher https://code.visualstudio.com/api/working-with-extensions/pu...

bdcravens 3y ago

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.

dylan604 3y ago
Does the 45k installs mean for a specific extension or just that 45k installs in total of all extensions?
- bdcravens 3y ago
  I read it as any extension with more than 45k installs. If it's 45k total, that's a very small percentage of all installs.
  - ezfe 3y ago
    Right, but the one with 45k installs wasn't malicious - sending os version telemetry isn't PII stealing
- shzhdbi09gv8ioi 3y ago
  One of the extensions had 45213 installs, which is what the headline stated. But no matter how you count it, the rest of the extensions was far off 45k.
shzhdbi09gv8ioi 3y ago
I noticed that too, right from the headline "Malicious Extensions with more than 45,000 Installs" with a screenshot showing "278 installs". Exaggerate much?

andrewmcwatters 3y ago

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.

danenania 3y ago
I agree, but it's not a problem unique to javascript. I'm not aware of any popular language/runtime/package manager that goes beyond what Deno can do, however insufficient that is. It's quite a hard problem.
explaininjs 3y ago
The “right answer” afaik is to adopt the web permission model, which VSCode actually already supports. In addition to the Node extension host, there’s a WebWorker extension host which is much more secure (it’s the only host available on things like vscode.dev). Extensions need to opt into it unfortunately, but the code changes are not too bad in my experience.
hombre_fatal 3y ago
It’s a problem with security across computing in general, not just JS. For example, what are these languages and runtimes you have in mind that solve this issue with app plugins if VS Code were using them instead?
- andrewmcwatters 3y ago
  In other languages, it's possible to set environments where code run from that environment have restricted access to explicitly defined globals. You can do this to create things like plugin systems, etc, where you know by specification you never want a context to have access to say, making HTTP requests.

ianzakalwe 3y ago

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.

newaccount74 3y ago
Tracking your host name is not telemetry, it's definitely spyware.
- scotty79 3y ago
  Still, it's not nearly on the same level as exfiltrating secrets.
- cywick 3y ago
  Exactly. Typically, exfiltrating this kind of information is only the first step. Once enough high value targets are caught in this net, the actual malware is deployed.

nathants 3y ago

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.

garganzol 3y ago

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

8organicbits 3y ago
Name/typo squatting is deceptive and malicious. The telemetry helps the attacker detect when a valuable target begins using the software, enabling a targeted supply-chain attack.

calibas 3y ago

> 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...

siegecraft 3y ago

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.