Live data from Hacker News

AUR packages compromised with Infostealer and Rootkit

discourse.ifin.network

51–60 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#51
post #46

Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.

Nothing here is "fundamentally broken". Any usage of AUR was always one step above executing random shell scripts from the net, and any official Archlinux guides were explicit about it. That's why there are no AUR helper tools in official repos and their usage was always discouraged in forums/wiki. PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and r…

You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)

Re: AUR packages compromised with Infostealer and Rootkit

#53
Not the first time this has happened recently. There were a few emails in the AUR list a few weeks ago about malicious packages, and a few reports on IRC too. The only difference in the campaign back then was the malicious npm package name (`linux-utils` in the campaign a few weeks ago).

Re: AUR packages compromised with Infostealer and Rootkit

#54
post #44

Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.

> Guess I'll be switching to a new OS this weekend across multiple machines. This is a bit of an odd response. Arch very explicitly separates the AUR from everything else and doesn't make it easy to work with, because its security model has always been fundamentally broken and requires you to do your own vetting. It exists to facilitate sharing of package recipes between untrusted users. You should treat it like a pa…

> ...because its security model has always been fundamentally broken...

I disagree that "These packages are provided as-is. No work has been done to determine their safety or fitness for purpose. Use at your own risk!" is a "fundamentally broken" security model. It's one that places the burden of verification and validation on the system administrator and -in the case of the AUR- fully informs them of this fact. Treating system operators like the adults that they are isn't "fundamentally broken", but it is _much_ more work for that operator than if they relied exclusively on distro-vetted packages.

I do agree that it'd be fucking silly of OP to switch away from Arch because some of the packages in the collection of packages that are explicitly provided as "as-is and unvetted" got some malware in them.

Re: AUR packages compromised with Infostealer and Rootkit

#55
7+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this.

Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure that all malware was found.

Also there should be database of revoked/compromised AUR commits and there should be mechanism to warn user if they had it installed.

Re: AUR packages compromised with Infostealer and Rootkit

#57

I remember installing an emulator (Mednafen) on Arch Linux about a decade ago. The program failed to run because it was linked against a library my system didn't have. Turns out, the maintainer built the software on his own system and it used a library he had on his system but was not listed in the dependencies. It is an officially maintained package and I always assumed these were built on a dedicated build server i…

It's only relatively recently that this has shifted from the norm. Debian operated this way for a long time and it was only in 2019 that they forbade it entirely.

Re: AUR packages compromised with Infostealer and Rootkit

#58
post #37
post #4

This is especially gnarly as more people have been picking up arch distros as of late (like CachyOS).

On the bright side you can get quite far without the AUR. I have 1,135 packages installed. Only 3 top level packages are from the AUR and 2 of those 3 are from the same author, they just happened to split their packages into a client / server architecture.

This is similar to my situation with Gentoo. Across my Gentoo systems, I have exactly one package installed from an "overlay" [0], and that's Steam. Everything else is straight out of the official package tree.

[0] ...which is -IIRC- Gentoo's term for a user-provided and entirely-unvetted collection of packages...

Re: AUR packages compromised with Infostealer and Rootkit

#59
post #46

Earlier quoted context omitted.

Nothing here is "fundamentally broken". Any usage of AUR was always one step above executing random shell scripts from the net, and any official Archlinux guides were explicit about it. That's why there are no AUR helper tools in official repos and their usage was always discouraged in forums/wiki. PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and r…

You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)

Honestly, it's hard to see how Arch is a usable distro for most potential users without AUR. If you want a large selection of official packages, the Debian world is going to be the better choice.

Re: AUR packages compromised with Infostealer and Rootkit

#60
post #3

Earlier quoted context omitted.

It isn't guaranteed that the list is conclusive. Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.

> hasn't happened earlier. it happens all the time Just not always on this scale and doesn't always end up on HN. Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN. In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources…

I have opencode review it for me. Works great. With the opencode-pty plugin it operates a terminal like a human would, runs yay, opens the pkgbuild in vim when yay asks it, reviews, etc etc. gives an `n` at the end cancelling the operation and gives me a report. I read that and then upgrade. For non-famous 3-4 aur packages I have, I have it read the code itself. It's enough to catch the non-jia-tan problems.
Post reply on HN