Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

embedding-shape

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.

tryauuum

How bad was it?

anthonj

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.

Havoc

As I undertood it this was mostly orphaned packages?

robby_w_g

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.

bitmasher9

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

w4yai

"linux has no malware, windows bad boooh"

rvz

Who's on Arch Linux btw?

mkayokay

So from a quick read, it seems it installed "atomic-lockfile", "js-digest" or "lockfile-js" from npm. A list of affected packages is here [1]. 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

landdate

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

28304283409234

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'?

shevy-java

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

sunshine-o

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. - [0] https://pkgs.alpinelinux.org/package/edge/community/x86_64/c...

fooqux

For those worried, I found a repo with a collection of up-to-date scripts and package lists to help check for any infections: https://github.com/lenucksi/aur-malware-check

Simulacra

This is my fear with Linux and privacy - malware that leaks private data while using ie Tor, or other "anonymous" programs.

1vuio0pswjnm7

What perecentage of Arch users compile the kernel and userland software from source What Linux distribution^1 has the highest percentage of users who compile from source Is it Gentoo 1. Besides Linux from Scratch

smetannik

I might be wrong, but this situation seems like a signal of desktop Linux adoption growth

aftbit

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.

0x59

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)

scarlehoff

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.