I'll note that OpenSuse also has Packman which a shitton of people enable (for codecs), has also 'one namespace only' an looser policies than the main distro.
I do not think this something you can escape by switching distro.
In case anyone missed it, the latest version of yay (v13+) supports being able to skip recently added packages through its new Lua extension system https://jguer.github.io/yay/lua.html#upgrade-selection-hooks. You can control the threshold since it's just user configuration now.
Despite that official Arch repos weren't affected in this attack,
I would not recommend using Arch (or any rolling release distro)
for anything that requires security.
(Imagine if the xz backdoor targeted Arch...)
An Arch maintainer that I personally know once admitted that he
rarely review upstream changes when bumping package versions.
He only does that when the build breaks.
I can't blame him for what he did, since it's not reasonable to
ask package maintainers to spend all their time on those stuff,
especially in this "Age of AI" where more and more software are being
aggressively refactored (or rather rewritten) and added more features.
What we can do is choosing a stable distro (like Debian) where
packages are more thoroughly reviewed, and apply security practices
(such as TOTP, sandboxing browsers and video players, etc.)
even though they cause inconvenience.
This is a good thing, because the warning about checking everything you download from the AUR, which has always existed, is now actually "enforced". People respond to consequences.
Note that the AUR attacks were part of the larger miasma worm campaign, gradually trying to gain more control through various package ecosystems since the RedHat prototype campaign.
A side note, isn't package maintenance something that can actually be solved to some extent by LLMs? The prompt would be something like "Clone this repo and build this package while building/bundling as few other packages as possible with minimal code changes."
Then set it in a loop on all the packages for a particular system, I don't have experience in package maintenance and would be curious what kind of issues would come up.
The AUR really has been known to be low-hanging fruit for bad actors, which makes it somewhat surprising it took this long for it to be taken advantage of.
I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach.
But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.
The bad news, of course, is that the Linux desktop is a bit of a train wreck in terms of security hygeine. It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, and I fully expect we'll also see more malware propagated through KDE's New Stuff integration (which goes through Pling.)
> New user registration was stopped on June 11 and then re-enabled after the project added Anubis to try to foil the attacker's mass account registrations. That did not work
This confuses me - why would a proof-of-work anti-scraping system like Anubis prevent registrations?
Well all of those attacks are just supply chain attacks, and it is basically exploiting people's trust. With LLMs, the speed and velocity of pumping out malice raised are now significantly faster.
It is so sad that every goodwill eventually got enshittified as well.
The AUR is effectively a pastebin for PKGBUILD files.
Some people (many of which don't even use Arch itself) have been treating and advertising it as something different. It's not a software distribution method meant for normal computer users.
Humble question: how do you find out if your system has been affected by a malware?
I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any?
I haven't run an antivirus since I last used Windows 20 years ago.
> Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any?
>
> I haven't run an antivirus since I last used Windows 20 years ago.
That'd be the role of an IDS (Intrusion Detection System). Things like file signatures of your entire system being saved to another machine (for example an offline/airgapped one) beforehand (for example by plugging your main machine's SSD as a secondary drive on the airgapped one).
If you suspect shenanigans, you take your machine offline, you remove its SSD (your BIOS/UEFI is also a concern), plug it to your airgapped machine with the IDS: it compares all the files (binaries, config files, etc.)' checksums with the past ones.
It's a bit of a lost art but it could make a comeback seen what we're facing, now nearly on a weekly basis.
Some distros have a way to check for file integrity as part of the package manager: but you can't trust the infos coming from the machine itself if it's been compromised.
The funny thing is: with FOSS you know what's going on attack-wise as they are transparent , but there must be huge upheaval in the closed source (e.g. MS) software that is just kept quiet by stock-price-chasing executives.
A lot of people in this thread seem to be treating this situation as a referendum on the security of package repositories that allow anyone to create a package. Possibly because that's interesting to more people, since npm and PyPI are more widely used than Arch.
But unless I've badly misunderstood something, the key thing that made this attack possible is this "orphaned" thing that lets you grant write access to an existing package to the first person who claims it, without any control over who that is. I don't see how this could ever be a safe thing to do, I'm not aware of any other package repository that has it, and I struggle to guess what whoever built it was thinking. If AUR just turned off that misfeature, they wouldn't be having this problem.
(The article quotes someone involved as saying that the "orphaned" feature is good because good actors can also use it, but that seems irrelevant if it also opens up an unmitigable machine-takeover vulnerability. World-writable single-namespace systems like Wikipedia work by having humans proactively checking for bad changes, and also by it not being that bad if a page is briefly defaced, since you can't push malware to users' machines that way.)
there have been multiple package list checkers released, but unclear which ones are trustworthy, I can't immediately find a list from the official channels (through AUR website) to such approved scanners?
What is a good review? Or different tiers of review? When thinking about packages, say in npm world, I still wonder about trust within nested dependencies. New users might also be unfamiliar. Any thoughts or any guidances?
20 comments
[ 3.6 ms ] story [ 44.1 ms ] threadI do not think this something you can escape by switching distro.
A bunch of common yay commands also return back the last updated time of a package thanks to https://github.com/Jguer/yay/pull/2846.
An Arch maintainer that I personally know once admitted that he rarely review upstream changes when bumping package versions. He only does that when the build breaks.
I can't blame him for what he did, since it's not reasonable to ask package maintainers to spend all their time on those stuff, especially in this "Age of AI" where more and more software are being aggressively refactored (or rather rewritten) and added more features.
What we can do is choosing a stable distro (like Debian) where packages are more thoroughly reviewed, and apply security practices (such as TOTP, sandboxing browsers and video players, etc.) even though they cause inconvenience.
This is a good thing, because the warning about checking everything you download from the AUR, which has always existed, is now actually "enforced". People respond to consequences.
Mitigation Tool: https://github.com/cookiengineer/antimiasma
Blog Post with details: https://cookie.engineer/weblog/articles/malware-insights-mia...
Then set it in a loop on all the packages for a particular system, I don't have experience in package maintenance and would be curious what kind of issues would come up.
I have many opinions regarding this situation, but it mostly doesn't matter. AUR staff and AUR helper developers will figure out what they want to do, hopefully they will find a good approach.
But what I personally take away from this is simply that it has become worth it to target desktop Linux with malware. Or at least, moreso than previously. It is perhaps a good sign in some ways that the desktop is starting to be taken more seriously.
The bad news, of course, is that the Linux desktop is a bit of a train wreck in terms of security hygeine. It's getting better, and Linux does have the advantage of having some powerful primitives to exploit, but the desktop suites come from a totally different world, and I fully expect we'll also see more malware propagated through KDE's New Stuff integration (which goes through Pling.)
This confuses me - why would a proof-of-work anti-scraping system like Anubis prevent registrations?
It is so sad that every goodwill eventually got enshittified as well.
Some people (many of which don't even use Arch itself) have been treating and advertising it as something different. It's not a software distribution method meant for normal computer users.
I know that for AUR there was a specific list of affected packages (that I checked, and haven't installed any of them), but I'm interested more in a general way. It could be from AUR, npm, or many other sources. Some malware could break and lock immediately the system, but other could stay there silent for months, so how to find out if there is any?
I haven't run an antivirus since I last used Windows 20 years ago.
That'd be the role of an IDS (Intrusion Detection System). Things like file signatures of your entire system being saved to another machine (for example an offline/airgapped one) beforehand (for example by plugging your main machine's SSD as a secondary drive on the airgapped one).
If you suspect shenanigans, you take your machine offline, you remove its SSD (your BIOS/UEFI is also a concern), plug it to your airgapped machine with the IDS: it compares all the files (binaries, config files, etc.)' checksums with the past ones.
It's a bit of a lost art but it could make a comeback seen what we're facing, now nearly on a weekly basis.
Some distros have a way to check for file integrity as part of the package manager: but you can't trust the infos coming from the machine itself if it's been compromised.
But unless I've badly misunderstood something, the key thing that made this attack possible is this "orphaned" thing that lets you grant write access to an existing package to the first person who claims it, without any control over who that is. I don't see how this could ever be a safe thing to do, I'm not aware of any other package repository that has it, and I struggle to guess what whoever built it was thinking. If AUR just turned off that misfeature, they wouldn't be having this problem.
(The article quotes someone involved as saying that the "orphaned" feature is good because good actors can also use it, but that seems irrelevant if it also opens up an unmitigable machine-takeover vulnerability. World-writable single-namespace systems like Wikipedia work by having humans proactively checking for bad changes, and also by it not being that bad if a page is briefly defaced, since you can't push malware to users' machines that way.)
https://forum.endeavouros.com/t/malicious-aur-checkup-script...
https://github.com/lenucksi/aur-malware-check