Active AUR malicious packages incident : linux@programming.dev

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

permalink

fedilink

source

parent

hideshow 8 child comments

[–] brucethemoose@lemmy.world 5 points 4 months ago* (7 children)

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.

permalink

fedilink

source

parent

hideshow 7 child comments

[–] octobob@lemmy.ml 3 points 4 months ago (6 children)

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.

permalink

fedilink

source

parent

hideshow 6 child comments

[–] brucethemoose@lemmy.world 2 points 4 months ago* (5 children)

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).

permalink

fedilink

source

parent

hideshow 5 child comments

[–] octobob@lemmy.ml 1 point 4 months ago* (4 children)

I've been doing a lot of reading online tonight about this whole ordeal. Someone mentioned CachyOS "makes it easy to install apps" or something in that vein as in it utilizes one click solutions for installing, so to speak. If these point to the AUR without checks and balances then yeah I could see that being quite a disaster.

I'm not sure I follow what you mean about better flatpak integration. Arch and flatpak play pretty nicely together as it is. It's just my experience that a lot of the more random and niche software I want is only available via the AUR and not flatpak.

Ultimately though, the AUR is the arch user repository. As in, it's maintained and contributed to by users, not the Arch Linux team that develops the distro. They provide plenty of warnings about using it at your own risk, and while it's certainly a big part of the appeal for the distro, it's no surprise that something that's basically the wild West will get a little unruly at times.

permalink

fedilink

source

parent

hideshow 4 child comments

[–] brucethemoose@lemmy.world 1 point 4 months ago* (3 children)

I am away from my CachyOS desktop for tonight, but I’ve never seen an “AUR GUI” like Manjaro was notorious for pushing.

They do build some AUR packages themselves and put them on the official repository. One of them is Paru, yeah, but it’s not a default.

But I think the “installing apps” thing is Flatpak. I don’t use any flatpaks at the moment, so don’t quote me on that until I check later.

permalink

fedilink

source

parent

hideshow 3 child comments

[–] octobob@lemmy.ml 2 points 4 months ago (2 children)

All that a flatpak is is a distro-agnostic release of a package. They contain all the binaries and libraries to run on any distro. They're also sandboxed from the rest of your OS unless you give them permission to interact with it. Being that they contain everything for all of Linux means slightly larger file size, but that's not so much of a problem as it was in the old days.

I install flatpaks via terminal, same as I do for official repos stuff and the AUR. I was never a fan of GUIs for really anything on Linux other than my file browser, but especially not for updating or installing packages. There's too many prompts and dependencies.

permalink

fedilink

source

parent

hideshow 2 child comments

[–] brucethemoose@lemmy.world 2 points 4 months ago* (1 child)

The separate libs is indeed my concern.

I like using my optimized system packages. I like how they’re all built against each other, especially for some things where performance depends on certain libs.

But, probably more importantly, my OS partition gets pretty tight, and I want to reduce duplicated libs where possible. I could probably do something about that (like put Flatpak on a separate drive), but I guess I also have a bad experience with docker taking tens or even hundreds of gigabytes and tons of RAM for simple projects.

EDIT: …I didn’t meant to go on an anti flatpak rant. I’ve used it on other systems. TBH I might try it soon, but most everything I need is in my distro repo anyway. Or something I install/build manually.

permalink

fedilink

source

parent

hideshow 1 child comment

[–] octobob@lemmy.ml 1 point 4 months ago

All good! You sound like you're on the right path. I have like 3 or 4 flatpaks installed hahaha

permalink

fedilink

source

parent

[–] A_norny_mousse@piefed.zip 5 points 4 months ago* (last edited 4 months ago) (1 child)

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.

permalink

fedilink

source

parent

hideshow 1 child comment

[–] chameleon@fedia.io 5 points 4 months ago

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.

permalink

fedilink

source

parent

[–] ulterno@programming.dev 1 point 4 months ago

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.

permalink

fedilink

source

parent

[–] brucethemoose@lemmy.world 15 points 4 months ago* (last edited 4 months ago)

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.

permalink

fedilink

source

[–] brucethemoose@lemmy.world 10 points 4 months ago* (1 child)

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.

permalink

fedilink

source

hideshow 1 child comment

[–] A_norny_mousse@piefed.zip 5 points 4 months ago

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.

permalink

fedilink

source

parent

[–] Tim_Bisley@piefed.social 7 points 4 months ago

I feel like attacks like this is a big vulnerability of user repos. That list is not insignificant.

permalink

fedilink

source

[–] Equinox1289@sh.itjust.works 6 points 4 months ago (6 children)

This is why I prefer Flatpaks, or really any application sandboxing.

permalink

fedilink

source

hideshow 6 child comments

[–] Ooops@feddit.org 7 points 4 months ago

People not even checking the PKGBUILDs will also not check sandboxed applications to see if it was actually done properly...

permalink

fedilink

source

parent

[–] 9tr6gyp3@lemmy.world 6 points 4 months ago (4 children)

AUR packages can be sandboxed with many different solutions. Any pckage can be sandboxed really.

permalink

fedilink

source

parent

hideshow 4 child comments

[–] defaultusername@lemmy.dbzer0.com 9 points 4 months ago* (3 children)

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.

permalink

fedilink

source

parent

hideshow 3 child comments