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

(It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)

After using Void Linux I switched to `aurutils` to get a similar separation on Arch. I can easily maintain a local AUR repo by compiling/making my own binaries and can use `pacman` to install and manage them which improves the upgrade process overall.

The pacman wrappers you mention are crazy, though.

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…

Perfect demonstration!

Then I just update when I need to update

I recently worked up a patch [1] for pakku [2], after being inspired by pnpm.

[1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...

[2] https://github.com/zqqw/pakku

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

Get a list of installed packages originating from AUR using 'yay' :

  yay -Qam > packages_aur.last

  curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt

  grep -wFf compromised.txt packages_aur.last

I'm willing to bet you yourself have read <1% of the source code currently running on your computers. Does this mean you have stopped using your computer(s)? How can you trust anything that happens on them?

I think this stance should be re-evaluated. Arch Linux developers are doing a fantastic job and I am personally thankful to them - this is not in any way critical of them. And while I don't see an easy solution here, I just feel that the time of "warning users" is long gone with how much supply-chain attacks are ramping up these days.

Some other controls could at least alleviate the problem. Perhaps some form of peer-review and grace period before publishing could help here?

It's crazy that all it takes to become a maintainer of a package is to flag it as orphaned, wait 2 weeks for the original maintainer to fail to respond because they're on a holiday, and BAM! - the attacker can gets assigned as a maintainer and can now ship spicy updates.

There’s bits and pieces of this in place with immutable distros, Wayland, and Flatpak but notable holes remain. The biggest one is that sandboxing is tied to the package format which I think is a mistake. Sandboxing and access permissions should be a system-level thing so even arbitrary binaries can’t easily slip through the cracks.

This wouldn’t fix the problem entirely, but it’d greatly limit the blast radius and make users of the distribution a less juicy target.

What review should users do?

It appears that, in some cases, these were adding npm as a dependency and installing atomic-lockfile, and in others, these were adding bun and installing js-digest. This was a mass attack against mostly low-use/orphaned/etc packages where maintainership was taken over or a different user uploaded a new version (itself a very simple, low-notice, low-oversight process), and many of the packages clearly had no connection to Node.js at all, so a user who knew enough about each package, and knew what npm was, might notice the oddity in the package, if they reviewed every line of the PKGBUILD, then reviewed the install scripts.

But legitimate AUR packages for packages connected to Node.js also use npm, for example, and at times, use npm install. A user would have to be familiar enough with Archlinux's build system to understand the difference between each part (eg, build() vs install scripts). They'd have to review every PKGBUILD, every install script, and every patch of every AUR package they install. For packages that actually do use npm/bun, they'd have to be familiar enough to know what uses were legitimate and what uses were not, and might have to be up to date on compromised dependencies. And this is still considering a mass attack that was not particularly hidden. Attacks could be made much harder to find.

Asking a user to safely review an AUR package essentially seems like it is asking them to fully understand not just the build process, and programming language, of the upstream package, but also all details of Archlinux's build system. They need to learn how to do this with, as far as I can tell, no real guidance: AUR itself, and the wiki's page on it, just warn that users should carefully review the PKGBUILD and install scripts, without giving any substantial guidance on what to look for or how to review anything. The warnings feel much more like liability-reduction than an attempt to be helpful.

At that point, what is AUR actually offering that installing the upstream package isn't? It feels like the suggested 'safe' way of using AUR would make it just as much work for the user, and require just as much knowledge, as either installing the upstream directly, or even making a package for it.

There is perhaps some room for LLM analysis here: Opus 4.8, Kimi latest, and even Qwen3.6 27B quickly catch at least the current round of malicious packages in my tests. But a motivated attacker could make that more difficult, or dangerous. And a user could also just have those models install the upstream package, with less risk. If they want to use pacman for management, they could likely even have those LLMs generate a package, with less risk.

For a distro this popular I’m surprised how much is in unofficial repos(AUR) and not the official ones.

QBASIC. When you need a package you type it in from a magazine. Virtually anything you could ever need is only 1-12 weeks away.

Most distros are too. All the big distros have pretty good track records.

The malware was limited to package sources that I understand to be disabled by default, if you're using Arch Linux. These package sources carry clear warnings that the packages they provide are controlled by third-parties and entirely unvetted by the distro maintainers. [0][1]

If your assertion is that any package management system that permits the installation of packages that aren't vetted by the maintainers of the -er- OS that uses that package management system is "not doing it securely", then the only one that's even vaguely "doing it securely" is Apple's iOS.

I'm of the opinion that permitting users of a general-purpose computer to install arbitrary software is a good thing, and is pretty much the entire point of a general-purpose computer. I'd call computers that make that effectively impossible "appliances". There's very definitely a place for appliances, [2] but seeking to turn every computer into an appliance is massively destructive.

[0] <https://aur.archlinux.org/>

[1] <https://wiki.archlinux.org/title/Arch_User_Repository>

[2] Reliable computers that you never have to think about because they simply never fail to perform the useful tasks they were designed to do are great.

Everything will need to be run in a VM separated from your main desktop which should have your data and a minimal amount of apps.

Qubes OS was ahead of it's time.

Nothing I have ever used has a comparable dependency tree nightmare.

AUR is worse, in that there may not be official authors and you can take over releases of a package. Like, you’ll have random users publishing the release for some application that doesn’t have their own Arch release. And if that user disappears, someone else may take it over

All major Node package managers should support it by now.

Prom was the best IIRC, yarn second, but even npm is catching up

Read the source. If you don't have the time then you shouldn't run the software.

`makepkg` will actively refuse to run if you are invoking it as root (unless you specifically invoke it with something like `env EUID=123 makepkg ...`).

> and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases.

I do wish pacman would support a user level installations. It will refuse to install packages as non-root (which you can go around by using user namespaces and mapping yourself to root).

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.

So with a dozen of various systems running arch/cachyos for various purposes, 0 impact.

We seriously dodged a bullet though, should we have some kind of AI spotting shady activity before it hits the userbase?

This was the AUR repository, which is the community-maintained soup of non-distro packages. They're packaged using the same tools and technology, with the intent that they can be easily validated and promoted to core stuff in the future. But they aren't really "Arch Linux". You need to deliberately enable and install tools to pull stuff from it.

Think of this as Steam or Chrome. You can install those on Arch, and people do, but if Chrome extensions or Steam games suffer an incident like this you don't blame the distro.

AUR comes with a warning that its up to you to check what you install from there.