Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm
Posted by FryBoyter@reddit | linux | View on Reddit | 42 comments
Posted by FryBoyter@reddit | linux | View on Reddit | 42 comments
Primary_Bad_3778@reddit
I misread that as "rpm" and panic washed over me...
jreykdal@reddit
I'm starting to think that this system isn't sustainable.
Don't we need a credential rotating mechanism that can rotate credentials constantly or something? Does it maybe exist?
natermer@reddit
People have been complaining about npm for years and how awful the dependency situation has been.
There is a LOT of issues going on and it isn't easy to fix.
A lot of is just the programming culture. People are lackadaisical when it comes to storing credentials on their desktops. They don't sandbox their development environments and store credentials in plain text files and such things.
They don't restrict the scope of the keys they use. They intentionally make keys last forever. They don't take advantage of things like Yubikeys to lock down credential stores, etc. They copy and paste keys into their bashrc files to have them always be available. They use plain text storage for usernames, passwords, and keys. Like store it into ~/.npmrc or ~/.netrc
(for example security keys like yubikey can emulate OpenPGP smart cards to store GPG2 private keys to be used with credential stores like Pass (passwordstore). This way when a application wants to have access to a secret it can flash the led on the card to prompt use to touch it and/or unlock the card with a key)
People also install packages for every little thing. Because of how packages depend on each other it is very easy to pull in hundreds of different packages for a single function that would require 20 or 30 lines of code to write yourself.
So it is easy to end up in a situation were you are installing thousands of packages, many times multiple versions of the same packages, for large projects without really thinking about it.
And it only takes one to compromise your system.
The way these worms are working is that once they infect a developer's system it goes and scans the desktop environment for credentials to log into various things. It will scan environment variables, look in common places to store keys, etc.
Then it will use that user's access to add pre and/or post build hooks into their CI/CD systems like github actions. These hooks inject code into the packages after they are being built, but before they are signed.
This way the worm code doesn't actually ever end up checked into git or show up anywhere obvious. But it still gets added and signed and shipped to go on and infect other developers.
atrocia6@reddit
Minor nitpick: most hardware security keys, certainly the cheaper ones, including Yubico's own "Security Key" model, do not have smart card functionality and do not support PGP. Yubico's flagship models do, but they cost about twice as much as its "Security Key."
UnluckyDouble@reddit
I don't want to be unfair and say that JS is a language for people who don't know what they're doing, but...
2rad0@reddit
Not only JS though, IMO it's any language that tries to automatically resolve dependencies from remote hosts instead of either including the full source code up front or having the programmer manually download it and properly install it as a root owned file.
FungalSphere@reddit
I mean nobody wants to pay for yubikeys so that's a nonstarter
natermer@reddit
yeah because sacrificing your professional career and everything you have spent years working for is far cheaper then spending 60 dollars and taking a afternoon to learn something slightly difficult. :P
My company ended up buying one for all the developers a couple years ago. But I was using them on my personal systems before that.
For anybody interested here is a nice comprehensive guide for using them:
https://github.com/drduh/yubikey-guide
It takes a 'paranoid' style approach to keeping your private keys 100% off any system except a specific live USB image. People may not like that, but even if you half ass it it still is going to be a improvement.
If the proprietary nature of yubikeys is unnerving there are open source alternatives out there. Also you could just go very old school with a actual OpenPGP compatible card and card reader.
For most normal personal password stuff I use Vaultwarden with Fido 2FA. But for things I want easily automated from my desktop I will use pass (password store) with its git integration.
Even if your application doesn't have plugins for pass the files are stored gpg2 encrypted, which a lot of programs do understand. Or it can be scripted. But a lot of things do understand it; I use it with ansible and Emacs, for example.
Easily the worst aspect of depending on this sort of stuff is misplacing your backed up keys, forgetting the pins and admin pins, locking yourself out of your key (which can only be recovered by resetting it) and such things. By default these things will lock themselves if you mistype your pin too many times. You can recover using a admin pin, but that can be locked out as well. The only way to recover after that is from backups and to reset (completely wipe) the opengpg store on the card.
So backing things up is critical. Flash drives don't have infinite lives either. Modern ones should last many years between being plugged into systems, but "should" is the operative word here.
Rotating out old GPG2 keys is a pain in butt as well.
So backing things up and occasionally testing them is important. Last thing you want is to lose your key or lock yourself out only to find out you can't use your backups. You can print out everything in "ascii armor" as backups and store them in a bank lock box as a last ditch disaster recovery.
Otherwise less important, but annoying aspects is accidentally starting up a gpg-agent in the wrong context (if you are using distrobox/toolbx, etc) and having to restart pcscd after you log into a system to get "gpg2 --card-status" to work.
FungalSphere@reddit
First of all you're supposed to buy two to be able rotate them out so that's actually $120+replacements because they're not repairable by design
Second that's still hard cash, foss developers barely make enough money through donations to not need a full time job. If you want developers to use yubikeys sponsor them first.
KnowZeroX@reddit
you can get a cheap Nordic nRF52840 and install Google OpenSK on it, a FOSS version of FIDO2 security keys
natermer@reddit
well:
A) you are a idiot, because yubikey wasn't even the subject of my original post. I replied with something that I tried to be helpful with, but you just ignored it and doubled down.
B) There are cheaper alternatives out there that will do similar things as I pointed out.
james_pic@reddit
The cost is probably less of a problem than the friction they introduce. They cost about the same as one of those clicky-clacky mechanical keyboards, or a basic set of Bluetooth headphones.
The real issue is that to get real value from a Yubikey or similar, you need to use it every time you log in to something or sign something, you need to have it physically present, so you can either keep it on your desk (and not have it when you need to log into something on your phone), or keep it on your keyring by the door (and have to go and get it every time you need to log in or sign something).
It's not long before you decide that's a pain, and that you'll have another GPG key that just needs a password, just for convenience, and that you'll set up TOTP on your phone as an alternate second factor. And before you know it, the Yubikey is dusty from disuse.
ChevalierVirer@reddit
FYI the Red Hat related security bulletin: https://access.redhat.com/security/vulnerabilities/RHSB-2026-006
-p-e-w-@reddit
What the fuck? There’s almost no information there, not even which versions are affected, during what timeframe they were available, and whether those versions have been yanked.
mattdm_fedora@reddit
It says:
wobblyweasel@reddit
there's no follow button ¯\\( ͡° ͜ʖ ͡°)/¯
sccrstud92@reddit
Are you logged in?
wobblyweasel@reddit
no but I see login to the see comments button. besides hopefully you don't need an account for critical updates?
-p-e-w-@reddit
Fair enough, hopefully at least the basics will be known soon.
stewie410@reddit
From my experience of CopyFail & DirtyFrag, they normally take a week or more to produce anything on their bulletins (longer to release fixes).
se_spider@reddit
Agreed. The compromise was announced by thirdparties yesterday. It took them 24 hours to put up a page that includes no information, less than the disclosure.
lmpcpedz@reddit
Maybe they couldn't figure out who their webmaster was
Jean_Luc_Lesmouches@reddit
We're here because people did not see leftpad as the wake up call it should have been
james_pic@reddit
You might be making a more subtle point than I realise, but this feels orthogonal to the leftpad problem.
For me, I think the lesson we should have learned from leftpad is "if it takes more than 10 dependencies to build a system that runs in a given ecosystem, then that ecosystem is rotten".
But the attacked packages weren't microdependencies, they were big ol' platform SDKs. The kind of thing that, even back in the old days, when adding a new dependency to your project meant ordering it on floppy disk, would still have been common to rely on. The kind of thing that would be in the list of 10 dependencies anyway, for things that used RedHat's cloud platform.
Jean_Luc_Lesmouches@reddit
It's not about having too many dependencies. What makes dependency injection so devastating is package managers that can modify already installed dependencies without anyone's control. That is exactly what leftpad showed.
KnowZeroX@reddit
It lets you make changes within same version? From what I understand that isn't possible, at best someone can make changes to a new version but if you lock your dependencies to an existing version, the package-lock file then stores sha hash so even if the servers are compromised it would detect an error.
Barafu@reddit
OK, people learned it. Instead of 500 dependencies, a project has only 300 now. What next?
Jean_Luc_Lesmouches@reddit
That's not really the problem here
KnowZeroX@reddit
Wait, what? A big company like redhat/ibm has a single person able to push commits live without others approval?
Veemenothz@reddit
What I find more interesting is not the increase of it happening now, is that it hardly happened before as it seems very 'easily done'. It's even gotten to the point where having a rolling release distro and updating your OS + or any packages carries a risk.
If updating your OS becomes a risk, then the OS is simply not safe.
On Apple / Windows updating your OS the only risk you have is downloading a vibe coded update that destroys your computer, especially in terms of Windows.
On all operating systems you have to watch out watch you download, execute or click, but it's going to be a hard sell to friends and family if something as basic as updating your OS is unsafe.
Already had a scare on my NAS system that I recently ran Trivy on, luckily not downloaded the compromised version that released after...
JockstrapCummies@reddit
Slackware slackers slacking to a victory yet again.
VayuAir@reddit
How does this Fedora? Does anybody have any clue. Fedora should be assumed to be compromised as well
kopsis@reddit
The distro isn't compromised. These are node.js modules developed by Redhat and distributed via npm (node.js package manager). This affects anyone who uses the packages (directly or indirectly via dependency) on any distro.
VayuAir@reddit
Oh my mistake, I thought the distro was infected. Having said is it confirmed by RedHat that any other package is not affected.
hagis33zx@reddit
It is a npm package for the Node Package Manager (JavaScript, etc.), not an rpm package.
Latlanc@reddit
Package distribution is DEAD.
lmpcpedz@reddit
The next move is cloud computing! all our packages will be safe there!!
ButtSpelunker420@reddit
lol what
FryBoyter@reddit (OP)
Malicious software has been distributed through services like npm or PyPI, and as we can see, this continues to happen on a regular basis.
That's probably what he means by “dead” from a technical standpoint. Because there is no solution.
kescusay@reddit
I have a personal project that has taken up all my non-work development time for quite a while, and doesn't involve JavaScript, while my work development projects all use locked package versions. So I haven't touched npm or yarn or any other JS package manager in months.
Honestly been feeling like I dodged a bullet lately.
jikt@reddit
Package distribution is DEAD.
piat17@reddit
pacman, dnf, apt, zypper?
Gone, reduced to atoms