• [object Object]@lemmy.ca
    link
    fedilink
    English
    arrow-up
    116
    arrow-down
    5
    ·
    14 days ago

    Can we stop using npm now?

    I swear to god the number of attacks like this or spawned from other attacks like this is fucking stupid. I’ve gender seen anything like it.

    • i_am_not_a_robot@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      48
      ·
      14 days ago

      This problem has nothing to do with NPM. Checkmarx was compromised last month, and during that compromise there were malicious VS Code extensions published to Visual Studio Code Marketplace. A Bitwarden developer says that somebody ran one of those malicious extensions, and GitHub API keys were stolen which were used in publishing the malicious CLI package.

      It’s probably better that it happened on NPM. If the CLI were only downloadable from the Bitwarden website, it would have likely taken longer for somebody to notice something was wrong.

      • realitaetsverlust@piefed.zip
        link
        fedilink
        English
        arrow-up
        17
        arrow-down
        3
        ·
        14 days ago

        Yes, but NPM has been had countless security problems, this isn’t a new problem. Even tho this instance is not a problem of NPM itself, it still has been proven as one of the most unreliable and insecure package managers out there.

        • wizardbeard@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          17
          ·
          14 days ago

          I’m not a particular fan of npm, but you’ll probably see this kind of thing with any package manager of similar size. More a matter of what’s the most attractive target than the package tech itself.

          • tjoa@feddit.org
            link
            fedilink
            English
            arrow-up
            3
            arrow-down
            1
            ·
            14 days ago

            But why does NPM enable post install scripts by default? Why is there no way to define a minimum release age for dependency versions? It’s just poor design choices.

    • LurkingLuddite@piefed.social
      link
      fedilink
      English
      arrow-up
      23
      ·
      14 days ago

      Genuine question. How is NPM more vulnerable than other repos? Haven’t similar supply chain attacks succeeded at least as well as this one through GitHub itself and even Linux package repos?

      • Serinus@lemmy.world
        link
        fedilink
        English
        arrow-up
        29
        ·
        14 days ago

        Larger standard libraries do a lot. It’s a lot harder to sneak vulnerabilities into the basic C# or Java or C++ libraries than it is to add a vulnerability to something one dude maintains in the javascript ecosystem.

        And since javascript libraries tend to be so small and focused, it’s become standard practice for even other libraries to pull in as many of those as they want.

        And it stacks. Your libraries pull in other libraries which can pull in their own libraries. I had a project recently where I had maybe a dozen direct dependencies and they ended up pulling in 1,311 total libraries, largely all maintained by different people.

        In a more sane ecosystem like C#, all the basics like string manipulation, email, or logging have libraries provided by Microsoft that have oversight when they’re changed. There can be better, third-party libraries for these things (log4net is pretty great), but they have to compete with their reputation and value over the standard library, which tends to be a high bar. And libraries made on top of that system are generally pulling all those same, certified standard libraries. So you pull in 3 libraries and only one of those pulls in another third party single library. And you end up with 4 total third party libraries.

        Javascript just doesn’t really have a certified standard library.

        (This certified standard library doesn’t have to be proprietary. Microsoft has made C# open source, and Linus Torvalds with the Linux Kernel Organization holds ultimate responsibility for the Linux kernel.)

      • hersh@literature.cafe
        link
        fedilink
        English
        arrow-up
        6
        ·
        14 days ago

        I don’t think you’ll find another major repo with so many real-world incidents though. Whether this is because of a systemic problem or just because it’s targeted more frequently, I’m not sure.

      • Kairos@lemmy.today
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        14 days ago

        There’s a lot of features that make it a better package manager but nobody cares. Every project has hundreds of dependencies and packages use a minimum, not exact, version.

        • LurkingLuddite@piefed.social
          link
          fedilink
          English
          arrow-up
          3
          ·
          14 days ago

          That sounds more like bad practices from the community. It definitely has ways to use exact versions. Not the least of which the lock file. Or the shrinkwrap file which public packages should be using.

          • Serinus@lemmy.world
            link
            fedilink
            English
            arrow-up
            3
            arrow-down
            1
            ·
            14 days ago

            Then you’re waiting forever on vulnerability patches. Especially if there are layers, and each layer waits to update.

    • anyhow2503@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      ·
      14 days ago

      Npm probably has the biggest attack surface and many of the libraries hosted there are in extremely widespread use. They’ve taken some steps to mitigate these supply chain attacks, but as we’ve seen with more recent examples, it’s unrealistic to think they can be prevented completely. Most of these attacks use stolen developer credentials, which invalidates almost all potential security measures on the registry side and the best you can hope for is catching a malicious package quickly. To be clear: I think the JS ecosystem is uniquely positioned to be the prime target of supply chain attacks and while that doesn’t excuse the slow implementation of security measures from the npm team, the people arguing that other package managers and registries aren’t vulnerable to this have to be huffing fumes.

      • [object Object]@lemmy.ca
        link
        fedilink
        English
        arrow-up
        5
        ·
        14 days ago

        That’s fair, I won’t pretend pypi/pip and running uvx is much safer than npx.

        But why hasn’t JavaScript established a defacto stdlib to replace ask the left pads and is even type packages?

        I’ve taken a near zero dependency policy on my personal projects regardless, and now I run most code in containers to sandbox it.

        • anyhow2503@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          14 days ago

          But why hasn’t JavaScript established a defacto stdlib to replace ask the left pads and is even type packages?

          I’m guessing things were working out pretty alright, even with the insane amount of dependencies per project. The awareness and the increasing frequency of supply chain attacks is relatively recent for npm. But who knows, maybe the tech giants in control of the web standards are happy to keep using their own vendored registries.

  • BlackEco@lemmy.blackeco.com
    link
    fedilink
    English
    arrow-up
    74
    ·
    14 days ago

    It has only been available for 2h30 on NPM, so unless you had the misfortune of installing the latest version in this short window, you should be fine. Thankfully people have been able to quickly catch this.

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    32
    ·
    14 days ago

    reposting the tl;dr I wrote from another community…

    Yesterday, for about 1h30min (starting at 5:57pm ET / 21:57 UTC) anyone installing the latest version of the command line interface of bitwarden was installing malware.

    The malware steals GitHub/npm tokens, .ssh, .env, shell history, GitHub Actions and cloud secrets, then exfiltrates the data to private domains and as GitHub commits and doesn’t seem to be targeting Bitwarden specifically, or user vaults.

    There’s no evidence that end user vault data was accessed or at risk, or that production data or production systems were compromised, according to their official statement.

    It seems there were 334 bitwarden CLI downloads in this time period, some or many of which might have been from bots, so this is a higher bound to the number of affected users.

    • Corngood@lemmy.ml
      link
      fedilink
      English
      arrow-up
      8
      ·
      14 days ago

      I really need to figure out a better sandboxing method for shells. It’s crazy to be things where my keys, browser data, shell history are all accessible.

      I do try to use firejail where possible, but it’s quite cumbersome. Every so often I look for tools to help with this, but everything is oriented around making a specific program (e.g. Firefox, steam) work.

      • Eager Eagle@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        14 days ago

        yeah, about twice a year I use the CLI to backup my vault, and I’ve never felt comfortable installing an npm package to handle my vault. Now I’m definitely sandboxing it in a rootless container without internet next time. And installing a week old version, or older.

  • quick_snail@feddit.nl
    link
    fedilink
    English
    arrow-up
    40
    arrow-down
    10
    ·
    14 days ago

    Don’t. Use. Npm.

    That applies to pip and crate and all the other shitty lang package managers that totally fail at security

      • quick_snail@feddit.nl
        link
        fedilink
        English
        arrow-up
        3
        ·
        14 days ago

        Yep. And so many workplaces have had security vulnerabilities caused by dumb decisions that could have been easily avoided

      • Victor@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        13 days ago

        We just recently switched from npm to pnpm, due to all the supply chain attacks. I did the PR for it, even.

        Our release schedule is like a year though so we don’t really have to worry much about releasing compromised dependencies. But still, better to be on the safer side.

    • rmrf@lemmy.ml
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      5
      ·
      14 days ago

      Honestly just fine use computers at all, completely eliminate the remote attack vector. And only drink rain water since city water can be compromised.

      Or, recognize this is a normal part of using software and have more than 1 thing between you and a breach

      • quack@lemmy.zip
        link
        fedilink
        English
        arrow-up
        20
        arrow-down
        1
        ·
        14 days ago

        The rules of cybersecurity:

        1. Under no circumstances should you own a computer.

        2. If you absolutely must own a computer, under no circumstances should you connect it to the internet.

        3. If you absolutely must connect it to the internet, it’s too late and they already have you

        • HubertManne@piefed.social
          link
          fedilink
          English
          arrow-up
          2
          ·
          14 days ago

          I know this is a joke but im old enough we used to install the os and had it on the network and eventually update it but then it got to the point were like being connected to the internet for like a minute and the machines were compromised. Thats when we got off our duffs and started making custom installs that had updates and configurations and software pre installed before we even connected it to the net.

        • StarDreamer@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          5
          ·
          14 days ago

          And how would apt help in this particular case? A supply chain attack can happen with any particular package manager. In this case, the compromised package was detected and mitigated within 93 minutes, affecting a total of ~330 users. Which is a lot better than how a lot of distros handled the xz breach last year.

          All reasonably secure package managers (and https) operate on a chain of trust. There is little that can be done if that chain of trust is broken.

          Based on this the cause was a malicious VSCode extension that stole credentials that were later used to trigger a deployment CI/CD pipeline. If there’s anything to learn from this, it’s probably to not use VSCode.

            • StarDreamer@lemmy.blahaj.zone
              link
              fedilink
              English
              arrow-up
              3
              ·
              14 days ago
              1. If your assumption is that X509 is trash, does that mean you hold the same amount of distrust to TLS?
              2. How do you propose the scaling of key management? Do you have a reasonable alternative to users blindly trusting every single key they come across?
              3. Back to my original question: what prevents a VSCode extension from stealing a private signing key (as opposed to an API key) and causing the same issues described here?
    • wizzim@infosec.pub
      link
      fedilink
      English
      arrow-up
      1
      ·
      14 days ago

      Unfortunately I have to use node for home project (Jellyfin tizen)

      I was wondering: would it be possible to run node in a sandbox to lower the scope of the attack? (i.e. not compromise my home computer) Or is maybe a full VM a better solution?

  • mazzilius_marsti@lemmy.world
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    8
    ·
    14 days ago

    lots of people recommend bitwarden, but i am more at peace with an offline password manager that i control like Keepass. You can also go the GNU route and use “pass” on Linux too

    Or use a physical key like Yubikey to login

    • aeiou_ckr@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      14 days ago

      Only if yubibkey worked for more than the handful of sites/services. I have one for my bitwarden as majority of places want to send a text or us totp.

      • neclimdul@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        14 days ago

        Also they only half work in Linux I guess? Something about not being able to create something.

    • mlg@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      14 days ago

      I’ve been trialing Vaultwarden for a while and while I do like the server sync setup and clean web access, the Bitwarden browser plugin is just okay despite being an “enterprise” solution. It misses probably about 20% of websites when creating a new account, forcing you to grab the password from the generator history and make a new entry manually.

      KeepassXC is much better in that regard, and it’s almost as good as the default credential handler of Firefox, and it lets you set up a bunch of custom stuff to extend the functionality if you want. Plus it has some neat kbdx options aside from AES256.

      Only downside is syncing, which I’m debating how I’ll deal with something better than syncthing on android (protocol is great, android makes it a PITA to have a background process if its not Google spyware).

      • KyuubiNoKitsune@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        4
        ·
        14 days ago

        It misses probably about 20% of websites when creating a new account, forcing you to grab the password from the generator history and make a new entry manually.

        This makes me so fucking angry. How can a password manager be so bad at storing passwords, it’s like it’s only job. It even is generating the password for you! Aaaaaaaaaaaaaah!