Live compromised package list: https://md.archlinux.org/s/SxbqukK6IA
https://gist.github.com/Kidev/85756c3dcad3623ca5604a8135bafd14 - pulls list and checks installed packages.
Holy crap, so many!
Is this a concerted effort (by evil hackers)? (edit: yes. was.)
Can we still see an example of an affected PKGBUILD or git repo? I just tried some randomly and they all seem fixed already.
One example: https://aur.archlinux.org/cgit/aur.git/commit/?h=oracle-bin&id=eceeb808ef933a66285ea68cefd72c1b5f4374c9 . It seems the AUR team forcepushed the malicious commits out of the repo branches, likely to prevent being accidentally reused by git-bisect in the future, but the URLs still seem to work until they run garbage collection. The author/committer information on each affected commit impersonated a previous maintainer of that particular repository and isn’t real.
The whole thing essentially just boils down to adding a
cd /tmp; npm install [random crap]post-install hook to every abandoned repository they easily got access to, which itself had a post-install hook to set up malware things. npm has nulled the affected packages, though it took them somewhere around 24 hours to do so. atomic-lockfile was one of them.
lol I ran the script worried I’d have one as if I’ve updated a single package on my machine so far this month
I updated last night fuck my chungus life
I did two nights ago, but it doesn’t mean you got infected, necessarily. Packages got compromised at different times, so check your update history.
I did and it returned two hits for clang19 and compiler-rt19. They were on my PC for about a month from March to April. I’m not gonna lie, I don’t even know what those are, probably a dependency for something.
Fortunately they installed from the official repos according to my log. So I think I’m ok
Check this to be (more) sure:
https://github.com/lenucksi/aur-malware-check
(And obviously don’t trust me either, check the .sh with your eyeballs too).
Amongst other things, it checks the history of your installs/uninstalls, so takes the date into account. Hence I had installed graalvm, but fortunately it was never updated in the compromised window.
Yeah I’ve ran a few, including that one. Also manually checked all my AUR packages against the list and there are a few that are close, but not explicitly called out. Like filebot47 is an orphaned package and was called out as malicious, but I have regular filebot which is (I hope) ok. It seems the attackers were taking over orphaned packages and claiming themselves as a maintainer, which they were automatically granted after 2 weeks. I understand the idea of being able to contribute and work together in the Linux development world but this can be a recipe for disaster if left unchecked. It sucks people will take opportunities like this to inflict some real harm.
The only AUR packages I have are some of the more popular ones, and it’s only because that’s the only place I saw them available. I might look and see what I can install via flatpak if not in the official repos from now on.
It seems the attackers were taking over orphaned packages and claiming themselves as a maintainer, which they were automatically granted after 2 weeks.
Oh yeah. That’s not going to work anymore.
I think it’s just the cycle of enshittification from grifters. Once exploiting an ecosystem is “en vogue” in those malicious actor circles, users kinda just have to lock it down and/or migrate to another, as this is going to keep happening now.
Hence the AUR is not going to run on “reasonable goodwill” anymore. It can’t. That period is over.
I dunno what that means for Arch… maybe better flatpak integration? Or more app packaging in trusted upstream projects (like CachyOS in my case).
They even went for something as simple as
amdgpu-fancontrol-git, which doesn’t even get any updates!
btw I had just downloaded it separately and changed the script to match my stuff, so I wouldn’t have updated.
Holy heck, I barely dodged this.
I don’t have many AUR packages installed, but graalVM JDK8 was one of them and infected, and I did a paru update recently. Fortunately (looking at my update history) it wasn’t upgraded, so the package must not have been compromised just yet. Or maybe already rolled back, not sure.
I narrowly doged a similar bullet with PyTorch nightly from PyPi, not that long ago.
…It’s a good lesson, I guess. Shrink my AUR list to the absolute bare minimum, small enough to check pkgbuikds closely, and uninstall npm.
EDIT: And freaking use Docker and Flatpak, and partition my finances.
Also… yeah, this is a rather damning incitement against the AUR system.
It’s always been “install at your own risk,” but it doesn’t feel like the trust model is sustainable anymore.
this is a rather damning incitement against the AUR system
It’s not without good reason that Arch Linux never supported any AUR automation system beyond
makepkg. You are supposed to take a good look at the PKGBUILD before you continue.It’s mostly distros that integrated AUR into their package management that are gnashing their teeth now.
That said, the list of affected packages is mind-bogglingly long and I desperately want to know more about this. Can’t all be completely separate incidents.
I feel like attacks like this is a big vulnerability of user repos. That list is not insignificant.
This is why I prefer Flatpaks, or really any application sandboxing.
People not even checking the PKGBUILDs will also not check sandboxed applications to see if it was actually done properly…
AUR packages can be sandboxed with many different solutions. Any pckage can be sandboxed really.
This attack was executed by a script running in the PKGBUILD itself. You didn’t have to run the application to be infected since just building it will infect your machine.
It also had an install script that will be run as root when the package is installed. Can’t sandbox that.
Yeah, I bet the build process could also be sandboxed, but Im sure its not the default.
Sandboxing the build process would be a process. Nix already does it, for example. Many AUR packages don’t include a full list of dependencies.
