BlackEco@lemmy.blackeco.com
on 23 Apr 13:23
nextcollapse
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.
NotMyOldRedditName@lemmy.world
on 23 Apr 16:48
collapse
Pretty much with anything ya.
Unless there’s some super important thing I need in the latest release, if my shit works and there’s no security vulnerability, im in no rush to update.
eager_eagle@lemmy.world
on 23 Apr 13:41
nextcollapse
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.
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.
Anafabula@discuss.tchncs.de
on 23 Apr 14:18
nextcollapse
For cli I just use podman(/docker) containers. Good enough and I don’t have to learn a new tool
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.
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
on 23 Apr 15:13
nextcollapse
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
on 23 Apr 15:27
nextcollapse
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
on 23 Apr 15:58
collapse
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.
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
on 23 Apr 15:51
nextcollapse
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?
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
on 23 Apr 16:42
collapse
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.
Any security system based on expecting good behavior from people is sure to fail. If NPM has no estructural features to enforce safe behaviors, it is vulnerable by default. As no person using it will apply safe practices unless forced to. Specially if the default, easiest, less friction behavior, is inherently unsafe.
LurkingLuddite@piefed.social
on 23 Apr 19:08
collapse
I wouldn’t say pulling in higher versions is unsafe unless an attack like this succeeds. Otherwise it’s only an annoyance.
hersh@literature.cafe
on 23 Apr 16:22
nextcollapse
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.
As much as some people deride it Javascript is one of the most used languages on the planet.
This is basically the same as people thinking windows is less secure because it’s more often targeted.
JavaScript does have a bit of a problem with dependencies but it isn’t much different than other languages with built in package managers like rust. It’s just a bigger juicer target.
But Windows is less secure. Two things can be true at once. They are in the original topic too.
The Java ecosystem is massive and decades old and I don’t hear one iota of the shit about maven central that I hear about npm.
I guarantee that npm is full up with vibe coded bullshit at this point as well.
I’m not sure what it even takes to upload a package to npm. Not even a pulse. I honestly never looked into it because the whole ecosystem is so rancid.
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.)
I will almost always choose .NET as my development platform when greenfielding a project for exactly this reason. It’s an incredibly robust standard library that virtually guarantees I won’t need to pull in a litany of additional utility libraries, and I can also expect that what libraries I do choose to bring in are highly unlikely to drag along a ridiculous parade of dependencies.
InternetCitizen2@lemmy.world
on 23 Apr 21:15
collapse
Probably more worth than it was 15 years ago since you’re no longer restricted to Windows and it’s now open source. I’ve heard a lot of people say it’s nicer than Spring for enterprise stuff. Haven’t tried it much myself though. Was fairly easy to set up a simple API, but I then got distracted by other projects.
Yes, it’s incredibly nice, versatile, powerful and efficient. Me being a .net dev since first beta. That said it’s still a GC based runtime if that matters to you. I’m also looking more and more at kotlin as an alternative. If I was to look for a non GC language, I’d go with rust.
InternetCitizen2@lemmy.world
on 26 Apr 13:43
collapse
I have been wanting to get into coding for fun again and do some pet projects. Bit of a paralysis from choice.
It’s not, it’s a problem of every package manager that do not use sources and checksums, like rust and python.
Take a look at this article that does a better job then me at explaining the situation.
anyhow2503@lemmy.world
on 23 Apr 23:01
nextcollapse
The good news is that there already is a gold standard for supply chain security: the Go programming language.
Lmfao
bright_side_@piefed.world
on 24 Apr 01:13
collapse
Competent standard lib + decentralized libs + checksum db.
While the article is a bit theatralic, it offers important arguments.
There are some good points in it, though I wouldn’t really consider go dependencies all that decentralized in practice and I don’t understand how checksum db will protect against supply chain attacks with stolen credentials, but I admit I haven’t looked into the details.
bright_side_@piefed.world
on 24 Apr 11:52
collapse
Yep you’re right, tampering before transmission is still possible. I think I agree with having a strong standard lib helping that considerably.
While the language of the blog is not objective, the “content” was better than expected 😊
arcterus@piefed.blahaj.zone
on 24 Apr 02:30
nextcollapse
In a recent analysis, Adam Harvey found that among the 999 most popular crates on crates.io, around 17% contained code that do not match their code repository.
17%!
Let me rephrase this, 17% of the most popular Rust packages contain code that virtually nobody knows what it does (I can’t imagine about the long tail which receives less attention).
Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.
In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.
EDIT: Also, I just noticed that he called it a “recent” analysis. It’s roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.
AnarchistArtificer@slrpnk.net
on 24 Apr 08:30
nextcollapse
Thanks for the link. There have been a few people in this thread making this point, and I was considering asking them to elaborate so that I can gauge what my risk is from using pip for python. I appreciate you providing a resource so I can go learn more about this
17% of the most popular Rust packages contain code that virtually nobody knows what it does
That’s not true at all, the article where he got that information from says:
Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.
So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.
He then lists some ways packages can be maliciously compromised:
Steal credentials and impersonate a dev
Misleading package names
Malicious macros (this one is interesting, had never considered it before)
Malicious build script
And his solutions are:
Bigger std library (solves none of the above)
Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn’t match the source and is detectable)
Decentralized packages (which worsens every security concern)
Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)
Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.
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.
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
on 24 Apr 07:47
nextcollapse
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.
savedbythezsh@sh.itjust.works
on 24 Apr 12:03
collapse
If you’re asking why there isn’t one shipped with JS, the answer is because JS is built for the web, and the “don’t break the web” rule makes changing things in JS hard, as well as browser devs pushing back hard on anything that increases install size.
If you’re asking why as a community, we haven’t agreed on a single package to be a stdlib - lodash.
superglue@lemmy.dbzer0.com
on 23 Apr 15:31
nextcollapse
If I use the CLI through the bitwarden flatpak am I OK?
SaltySalamander@fedia.io
on 23 Apr 14:41
nextcollapse
It would seem to me that npm simply cannot be trusted anymore.
Kind of, but if the backdoor is months old some hours don’t seem like they should matter.
KairuByte@lemmy.dbzer0.com
on 23 Apr 18:18
collapse
Zero day goes brrrr
mazzilius_marsti@lemmy.world
on 23 Apr 20:24
nextcollapse
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
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
on 24 Apr 01:25
collapse
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!
Humans are required to solve a malicious insider. But most supply chain vulns of these shitty software dependency managers were resolved decades ago by freely available cryptography
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?
captcha_incorrect@lemmy.world
on 24 Apr 02:33
nextcollapse
In case of NPM version pinning is a good practice. But also set it to ignore post install scripts. They are a bad practice and only about 2 % of all packages use it so it is unlikely it will bother you. They, the post install scripts, were used in recent supply chain attacks btw (the axios). You can either set it project wide in .npmrc file, add ignore-scripts=true, that is good for project where multiple people collaborate. And/Or system wide by running npm config set ignore-scripts true for your personal workspace. You can also achieve it by using --ignore-scripts flag during npm install, but that is way too impractical to always think about it.
Also I would recommend checking npq, its a wrapper around npm cli that will give you some security summary before installing anything (and it is able to give you warning about post install scripts).
captcha_incorrect@lemmy.world
on 27 Apr 07:20
collapse
Wait, any package that I download via NPM could potentially have a script that will run unless I set it to false, when I install said package?
Yes, that is exactly how the axios supply chain attack worked… It ran post install script (on dependency) that downloaded malware, ran it and even cleaned it up. Everything on that machine was compromised…
It can be any dependency of dependency too, deep down in the tree…
captcha_incorrect@lemmy.world
on 28 Apr 00:40
collapse
Hmm. I was going to say that it sounds bonkers what it can run just any script, but at the same time, is it any different from downloading and executhing a binary file?
PumaStoleMyBluff@lemmy.world
on 24 Apr 05:38
nextcollapse
Technically you can use node without npm.
quick_snail@feddit.nl
on 24 Apr 06:34
nextcollapse
Full VM and network isolation. and dont put anything important there (nor a reused password for auth)
If you absolutely must own a computer, under no circumstances should you connect it to the internet.
If you absolutely must connect it to the internet, it’s too late and they already have you
HubertManne@piefed.social
on 24 Apr 08:24
collapse
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.
quick_snail@feddit.nl
on 24 Apr 06:32
nextcollapse
Apt works great
stardreamer@lemmy.blahaj.zone
on 24 Apr 08:45
collapse
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.
With cryptography. X.509 is trash. They should pin the public key.
stardreamer@lemmy.blahaj.zone
on 24 Apr 09:45
collapse
If your assumption is that X509 is trash, does that mean you hold the same amount of distrust to TLS?
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?
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?
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.
threaded - newest
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.
This is one of the reasons why I update a version or two behind. The other reason is because I’m lazy.
One lie and one truth in this sentence.
Laziness has some obscure advantages
I update after I feel all the early adopters have worked out all the bugs for me.
That is a genuinely good strategy.
Pretty much with anything ya.
Unless there’s some super important thing I need in the latest release, if my shit works and there’s no security vulnerability, im in no rush to update.
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.
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.
For cli I just use podman(/docker) containers. Good enough and I don’t have to learn a new tool
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.
Me when I break into a bank to steal the employee wallets
Npm is a fucking mess…
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.
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.
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.
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.
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.
What a fucking asanine series of events.
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?
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.
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.
Then you’re waiting forever on vulnerability patches. Especially if there are layers, and each layer waits to update.
Any security system based on expecting good behavior from people is sure to fail. If NPM has no estructural features to enforce safe behaviors, it is vulnerable by default. As no person using it will apply safe practices unless forced to. Specially if the default, easiest, less friction behavior, is inherently unsafe.
I wouldn’t say pulling in higher versions is unsafe unless an attack like this succeeds. Otherwise it’s only an annoyance.
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.
As much as some people deride it Javascript is one of the most used languages on the planet.
This is basically the same as people thinking windows is less secure because it’s more often targeted.
JavaScript does have a bit of a problem with dependencies but it isn’t much different than other languages with built in package managers like rust. It’s just a bigger juicer target.
But Windows is less secure. Two things can be true at once. They are in the original topic too.
The Java ecosystem is massive and decades old and I don’t hear one iota of the shit about maven central that I hear about npm.
I guarantee that npm is full up with vibe coded bullshit at this point as well.
I’m not sure what it even takes to upload a package to npm. Not even a pulse. I honestly never looked into it because the whole ecosystem is so rancid.
EDIT: Look at how many shits in this are optional (and note the overall quality of the article as well): dev.to/…/publishing-your-first-npm-library-51k2. The ecosystem sucks.
Part of the problem is also how many packages people bring in, even for the simplest of things.
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.)
I will almost always choose .NET as my development platform when greenfielding a project for exactly this reason. It’s an incredibly robust standard library that virtually guarantees I won’t need to pull in a litany of additional utility libraries, and I can also expect that what libraries I do choose to bring in are highly unlikely to drag along a ridiculous parade of dependencies.
Do you feel its still worth learning now?
Probably more worth than it was 15 years ago since you’re no longer restricted to Windows and it’s now open source. I’ve heard a lot of people say it’s nicer than Spring for enterprise stuff. Haven’t tried it much myself though. Was fairly easy to set up a simple API, but I then got distracted by other projects.
Yes, it’s incredibly nice, versatile, powerful and efficient. Me being a .net dev since first beta. That said it’s still a GC based runtime if that matters to you. I’m also looking more and more at kotlin as an alternative. If I was to look for a non GC language, I’d go with rust.
I have been wanting to get into coding for fun again and do some pet projects. Bit of a paralysis from choice.
Go with either kotlin or c#, I’d say. Both are high level and easy to start with. If you don’t have a preference, pick one of the two randomly.
Lol, LMAO even
Left-pad tho
As someone completely unfamiliar with the JavaScript mess, are these security issues specific to npm the actual repository or npm the package manager?
If it’s the latter, does using something else like yarn or bun instead help?
I think npm allows installation scripts which do make this worse, as a package can run arbitrary command at install time.
Npm has gotten a few config options that prevent this behaviour. We can only hope that they will become the default eventually.
It’s not, it’s a problem of every package manager that do not use sources and checksums, like rust and python. Take a look at this article that does a better job then me at explaining the situation.
Lmfao
Competent standard lib + decentralized libs + checksum db.
While the article is a bit theatralic, it offers important arguments.
There are some good points in it, though I wouldn’t really consider go dependencies all that decentralized in practice and I don’t understand how checksum db will protect against supply chain attacks with stolen credentials, but I admit I haven’t looked into the details.
Yep you’re right, tampering before transmission is still possible. I think I agree with having a strong standard lib helping that considerably. While the language of the blog is not objective, the “content” was better than expected 😊
Given that he lied about the results of the analysis he is using to prove his point, I find it hard to trust anything in this article.
In the analysis, Harvey said only 8 repositories did not match their upstream repos. The other problems were issues like not including the VCS info, squashing history, etc.
EDIT: Also, I just noticed that he called it a “recent” analysis. It’s roughly a two year old analysis. I expect things have improved a bit since then, especially since part of the problem was packaging using older versions of Cargo.
Thanks for the link. There have been a few people in this thread making this point, and I was considering asking them to elaborate so that I can gauge what my risk is from using pip for python. I appreciate you providing a resource so I can go learn more about this
That article has lots of issues:
That’s not true at all, the article where he got that information from says:
So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.
He then lists some ways packages can be maliciously compromised:
And his solutions are:
Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.
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.
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.
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.
If you’re asking why there isn’t one shipped with JS, the answer is because JS is built for the web, and the “don’t break the web” rule makes changing things in JS hard, as well as browser devs pushing back hard on anything that increases install size.
If you’re asking why as a community, we haven’t agreed on a single package to be a stdlib - lodash.
If I use the CLI through the bitwarden flatpak am I OK?
It would seem to me that npm simply cannot be trusted anymore.
Any package manager is prone to supply chain attacks, npm is now affected because of a shit tone of dependencies every package brings 🤷
Everyone should be using minimumReleaseAge (or their package managers equivalent) to block installing recently updated packages.
Doesn’t that cause issues if a backdoor happened a few months ago and you should be updating to a recent fixed version?
we can never win. it’s simply not allowed
It does. Enforcing a minimum package age can be useful for some applications, but the average user isn’t one of them.
Kind of, but if the backdoor is months old some hours don’t seem like they should matter.
Zero day goes brrrr
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
No. Offline password managers are also suspectible to supply chain risk.
I don’t think it uses npm though, that’s got to count for something
So is everything else. But KeePass has been a highly reputable password manager for close to 20 years now.
.
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).
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!
TIL about the generator history
Not super helpful, because every time you open it, it generates a new one, so how do you know which one is the one it generated?
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.
Also they only half work in Linux I guess? Something about not being able to create something.
I use Enpass since 1Password became shit. It’s alright.
I’ll just keep using keepass.
Keep ass?
Yeah, as in keep it closed so you don’t get fucked by the hackers.
You know it
Don’t. Use. Npm.
That applies to pip and crate and all the other shitty lang package managers that totally fail at security
What should be used instead?
Easy, just vendor all your dependencies! Can’t have a supply chain attack if you are the supply chain.
A package manager that uses cryptographic signatures. Apt had this since 2005 iirc. Use apt.
.
Packages are reviewed by package maintainers.
Humans are required to solve a malicious insider. But most supply chain vulns of these shitty software dependency managers were resolved decades ago by freely available cryptography
.
Apt is great, but it does not work with every language. As an example, you cannot use apt with maven (java) AFAIK.
Oh boy. Maven is like the only language dependency manager that does signing tho!
You don’t need to use apt for java. Just use maven :)
Haha! Yeah, I don’t even know where to start if I wanted to use apt for this. I’ll stick with Maven for Java.
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?
Wouldn’t verion pinning solve this problem?
In case of NPM version pinning is a good practice. But also set it to ignore post install scripts. They are a bad practice and only about 2 % of all packages use it so it is unlikely it will bother you. They, the post install scripts, were used in recent supply chain attacks btw (the axios). You can either set it project wide in .npmrc file, add
ignore-scripts=true, that is good for project where multiple people collaborate. And/Or system wide by runningnpm config set ignore-scripts truefor your personal workspace. You can also achieve it by using --ignore-scripts flag during npm install, but that is way too impractical to always think about it. Also I would recommend checking npq, its a wrapper around npm cli that will give you some security summary before installing anything (and it is able to give you warning about post install scripts).Wait, any package that I download via NPM could potentially have a script that will run unless I set it to false, when I install said package?
Yes, that is exactly how the axios supply chain attack worked… It ran post install script (on dependency) that downloaded malware, ran it and even cleaned it up. Everything on that machine was compromised… It can be any dependency of dependency too, deep down in the tree…
Hmm. I was going to say that it sounds bonkers what it can run just any script, but at the same time, is it any different from downloading and executhing a binary file?
Technically you can use node without npm.
Full VM and network isolation. and dont put anything important there (nor a reused password for auth)
Jellyfin is available in apt
I need to build it, jellyfin-tizen is a separate project for Samsung TVs
I think you need to throw out the Samsung TV to be secure
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
it’s much more convenient when you use something like btrfs-snapshots
The rules of cybersecurity:
Under no circumstances should you own a computer.
If you absolutely must own a computer, under no circumstances should you connect it to the internet.
If you absolutely must connect it to the internet, it’s too late and they already have you
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.
Apt works great
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.
With cryptography. X.509 is trash. They should pin the public key.
TLS is fine with certificate pinning m
That still leaves two out of three questions unanswered. Most importantly the last one, which was addressed towards the original complaint.
Dude, rain water is full of pollutants too. 😂
what about cargo?
Same problem.
use mozilla.github.io/cargo-vet/
so many workplaces I have been at used npm.
Yep. And so many workplaces have had security vulnerabilities caused by dumb decisions that could have been easily avoided
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.
What about using pip just to download basic common libraries for offline use?
Don’t do it.
Because they could be changed or have something sneak in the library?
Yeah, without signature checking anything that you download could change to anything else.
That’s a remote code execution vuln.
Does this include the brew version?
What is npm? How do I know I’m not using it?
Short answer: If you don’t know if you’re using it, you’re very likely not using it.
Npm is a package manager for node.js, a programming framework for JavaScript.
What is npm?
How did they find the problem that fast?