As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories.
`rua` and other similar CLIs make it really easy to review the packages before installing them from AUR too, and if you are doing banking on the same computer, you really have no excuse not to review the software you depend on. Keeping the amount of packages low, only use what you need, also makes this a whole lot simpler when it's time to upgrade.
I cringed hard when some people started to make pacman wrappers that could install from AUR directly.
I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.
AUR and similar repos for other distros scare the hell out of me.
Tutorials using them are so widespread… Start feeling like a weirdo for not wanting to give an unknown rando full indefinite root access to the system, with virtually zero peer review… all to install one version of a package where updates are undesired or infrequent…
You don't have to. The AUR is just a bunch of PKGBUILD text files, which if you don't feel competent enough to read and understand and trust, you can create your own local versions of and install from. It's just a recipe file that says download a program from this github URL, make sure the hash matches and then extract it and move the files to system directories.
I’ve made a point of not installing any AUR packages. It’s really tempting when there’s a package that’s not available via pacman, but at the end of the day I’d rather build from source myself or use a docker image.
Don't know if the packages delete themself after they run. I just wanted to provide some basic commands, as all the other infos I found didn't provide any help.
> It was bad enough when finding out more than 400 AUR packages for Arch Linux users had been infected with malware but now that number has risen to around 900 a few hours ago and now in the end at more than 1,500 user-contributed packages.been infected with malware
I never had a need for the AUR.
If I want a package not in the official repository I build it myself or if it has a binary release I will download it. this way i don't have to use root when building and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases.
At least in this way there is one less level of possible malicious code insertion in developer -> user, vs develeper -> maintainer -> user.
Could we be heading towards a world where it's just more secure to write inhouse software again, only now with AI agents? Not closed source per se, but 'own source'?
While this makes Arch Linux look bad right now, I recall how many years ago Gentoo was leading the pack with regards to having many clever people on board. Then came Arch Linux and eventually it put Gentoo as a second tier distribution. Arch has a lot of momentum; I myself am using Manjaro right now, primarily because it makes many things - including compiling from source - simple. As simple as Slackware, before Slackware fossilized (it's still alive of course, but just look at the most recent ISO release, then you'll understand the problem; when a distribution is no longer able to release .iso files, then it is in my book dead).
This is something that worries me with a distribution like Alpine Linux.
It is hard to avoid a package like chromium [0] or firefox which are in the "community" repo.
Now have fun check it at every update, this is not practically feasible.
For the web browser one can say we should use Flatpak anyway but there are a lot of other apps like sway from the community repo that cannot be flatpaked.
I'd expect no more than a fraction of a percent of Arch users compile the kernel and userland from scratch.
Gentoo may not have the highest percentage of users who compile from source because there's binary packages available now. Maybe Exherbo, Source Mage, or Lunar may have the highest percentage outside of LFS.
Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers.
I should be able to set a minimum package age just like I can with pnpm.
Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.
Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.
Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.
> Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.
Why not? I agree some limits should be added, but also shouldn't be too limited, then lots of things that could be properly maintained, won't. Maybe limit adoption to one package a month or something, to users registered since some date. But no one has automatic (& unreviewed) updates applied to their locally installed AUR packages (that'd be utterly bananas) so the attack vector is already pretty small here.
> Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.
No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-where-it-is-uploaded on GitHub. The code itself is dynamically renamed in its methods, re-used shuffled offsets for encrypted symbols, among other things. It's a mutating malware and the worst enemy from tools that rely on signatures.
Ironically, APT28/29 is somewhat relying on Microsoft being too slow to auto block users and repositories on GitHub that are the C2 infrastructure. Think about that for a second what this implies for your cyber strategy.
By the time you're able to scan signatures or "strings" you're already playing a cat and mouse game with a fully automated botnet, which you will never win. The only other ones I've observed during the last week that seem to be able to track this malware implant's changes were socket.dev. ALL other supply chain tools didn't even know about Miasma and re-invented it as a new campaign. They didn't have the skilled enough people nor toolchain to reverse the malware payload quickly enough to be able to keep up every 24h when they push out a new adapter for another ecosystem.
By fully automated I mean they're already using the credentials they stole less than 48 hours ago from a different package ecosystem, because the email addresses and names etc keep appearing from people who likely didn't even understand the impact of this self-spreading worm.
And having an IOC that checks for, let's say, any package that depends on bun won't help either because the malware will just use external means to re-download it. See the second PyPi campaign, where they just changed the dropper to use compressed WHL files and the setup.pth files that are auto-executed to download the dropper. They changed this after the PyPi maintainers flagged the first wave of malware droppers from the RedHat campaign.
As long as the package managers in those ecosystems aren't fully rewritten from scratch to accomodate for chroots, sandboxes, network and domain logs that are _only allowlistable per entry_ this won't change, and will stay being a feasible malware deployment strategy for supply chain attacks.
Repo for Mitigation Tool (I'm human so I play catch 21 with an LLM powered botnet) [1] ... Tech details in the blog post [2]
Also this is a problem across all package managers. Composer is also affected. Rubygems is also affected. NPM is also affected. PyPi is also affected. Go is also affected.
Nobody is talking about this, and I think this should be more openly discussed how much negligence and external trust we put in package managers in general. This really needs to change.
looks like I installed a package 3 weeks before it was comprised. I try to limit surface area as much as possible, and this package seemed to be required for a project I'm working on. (turns out it wasn't, but i didn't know that yet)
I like the aur wrappers for the convenience, but if I've already limited my AUR consumption quite a bit, I think from now on all aur updates will be manual.
One thing programs like yay could do though is to tie the packages to the maintainer. If the maintainer changes, it should be treated as a completely separate package. Not a perfect solution, but could avoid a few automatic upgrades.
There are 15k orphaned packages on AUR. I just adopted 3 rarely-updated ones this morning (sorting by most popular) and got them built. If you're using an orphaned package, consider adopting it so the baddies can't.
38 comments
[ 2.1 ms ] story [ 55.9 ms ] thread`rua` and other similar CLIs make it really easy to review the packages before installing them from AUR too, and if you are doing banking on the same computer, you really have no excuse not to review the software you depend on. Keeping the amount of packages low, only use what you need, also makes this a whole lot simpler when it's time to upgrade.
I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.
Then I just update when I need to update
Tutorials using them are so widespread… Start feeling like a weirdo for not wanting to give an unknown rando full indefinite root access to the system, with virtually zero peer review… all to install one version of a package where updates are undesired or infrequent…
Who is doing package management right these days? Who is doing it securely?
Didn't find any quick info on how to check a system, so I ran the following command to find foreign packages and some date related infos:
> pacman -Qmi
Check the output against the list of affected packages.
Then, you can also grep for those files in various locations: > grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
> grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
> grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
Don't know if the packages delete themself after they run. I just wanted to provide some basic commands, as all the other infos I found didn't provide any help.
[1] https://md.archlinux.org/s/SxbqukK6IA
Get a list of installed packages originating from AUR using 'yay' :
Get list from https://md.archlinux.org/s/SxbqukK6IA# : then : should spit out the packages that are in both files, hence were compromised at some point, I guess.I never had a need for the AUR.
If I want a package not in the official repository I build it myself or if it has a binary release I will download it. this way i don't have to use root when building and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases.
At least in this way there is one less level of possible malicious code insertion in developer -> user, vs develeper -> maintainer -> user.
It is hard to avoid a package like chromium [0] or firefox which are in the "community" repo. Now have fun check it at every update, this is not practically feasible.
For the web browser one can say we should use Flatpak anyway but there are a lot of other apps like sway from the community repo that cannot be flatpaked.
- [0] https://pkgs.alpinelinux.org/package/edge/community/x86_64/c...
What Linux distribution^1 has the highest percentage of users who compile from source
Is it Gentoo
1. Besides Linux from Scratch
Gentoo may not have the highest percentage of users who compile from source because there's binary packages available now. Maybe Exherbo, Source Mage, or Lunar may have the highest percentage outside of LFS.
I should be able to set a minimum package age just like I can with pnpm.
Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.
Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.
Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.
Why not? I agree some limits should be added, but also shouldn't be too limited, then lots of things that could be properly maintained, won't. Maybe limit adoption to one package a month or something, to users registered since some date. But no one has automatic (& unreviewed) updates applied to their locally installed AUR packages (that'd be utterly bananas) so the attack vector is already pretty small here.
No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-where-it-is-uploaded on GitHub. The code itself is dynamically renamed in its methods, re-used shuffled offsets for encrypted symbols, among other things. It's a mutating malware and the worst enemy from tools that rely on signatures.
Ironically, APT28/29 is somewhat relying on Microsoft being too slow to auto block users and repositories on GitHub that are the C2 infrastructure. Think about that for a second what this implies for your cyber strategy.
By the time you're able to scan signatures or "strings" you're already playing a cat and mouse game with a fully automated botnet, which you will never win. The only other ones I've observed during the last week that seem to be able to track this malware implant's changes were socket.dev. ALL other supply chain tools didn't even know about Miasma and re-invented it as a new campaign. They didn't have the skilled enough people nor toolchain to reverse the malware payload quickly enough to be able to keep up every 24h when they push out a new adapter for another ecosystem.
By fully automated I mean they're already using the credentials they stole less than 48 hours ago from a different package ecosystem, because the email addresses and names etc keep appearing from people who likely didn't even understand the impact of this self-spreading worm.
And having an IOC that checks for, let's say, any package that depends on bun won't help either because the malware will just use external means to re-download it. See the second PyPi campaign, where they just changed the dropper to use compressed WHL files and the setup.pth files that are auto-executed to download the dropper. They changed this after the PyPi maintainers flagged the first wave of malware droppers from the RedHat campaign.
As long as the package managers in those ecosystems aren't fully rewritten from scratch to accomodate for chroots, sandboxes, network and domain logs that are _only allowlistable per entry_ this won't change, and will stay being a feasible malware deployment strategy for supply chain attacks.
Repo for Mitigation Tool (I'm human so I play catch 21 with an LLM powered botnet) [1] ... Tech details in the blog post [2]
Also this is a problem across all package managers. Composer is also affected. Rubygems is also affected. NPM is also affected. PyPi is also affected. Go is also affected.
Nobody is talking about this, and I think this should be more openly discussed how much negligence and external trust we put in package managers in general. This really needs to change.
[1] https://github.com/cookiengineer/antimiasma
[2] https://cookie.engineer/weblog/articles/malware-insights-mia...
One thing programs like yay could do though is to tie the packages to the maintainer. If the maintainer changes, it should be treated as a completely separate package. Not a perfect solution, but could avoid a few automatic upgrades.