I use Debian btw
Thank god they’re only niche packages, right?
This attack is ongoing. Don’t let your guard down on AUR PKGBUILDs.
For people that just want to install packages that are not included in the Arch distro, and don’t have the knowledge or time to review PKGBUILD files:
Have a look into the Guix package manager. It works fine on top of Arch, and Guix has 31,000 packages now. Great for cross-language development and also suitable for early sharing of projects. npm support is a bit weak though, but packages written in Python, Rust, or functional languages are well represented.
I think the AUR is great if you are writing some program, want to explore some idea, and want to share it with people you know. Sharing freely is how all open source software is created initially. Open source needs that openness and could not exist without the creativity which the openness makes possible. That’s why Ubuntu for example has launchpad and ppas. But the AUR is not a good software distribution mechanism for people who just want to install and run stuff they have heard of, precisely because it is not vetted, and unsupervised. It can’t because the sheer number of packages it includes, over 114,000 .
By aware that the next target could be the Python / PyPy / pip ecosystem and repos. It is unsupervised, too, and users on average are less technical than Arch users.
“pip install” can run arbitrary code on your computer.
I suggest Guix because it is more looked after. It also has, which is essential, the openness mentioned above: You can pull any Guix package definition from your friend’s web site, and install it as any other package. You just need to configure the package source.
By aware that the next target could be the Python / PyPy / pip ecosystem and repos. It is unsupervised, too, and users on average are less technical than Arch users.
PyPi has been an attack vector for a long time now. Just as with NPM, and others.
I suggest Guix because it is more looked after.
What makes you say that?
In Guix, package definitions are part of the Guix distro and are vetted.
(You can still add your own local package definitions, or pull a package definition of your schoolmates friend from their web site or Codeberg repo - Guix is very open in that sense. But, in the same way as with Ubuntu launchpad and ppa’s or Debian third party repos, you would have to add that package source explicitly. It is not the standard way of distributing packages. )
Also, Guix is rapidly growing (31,000 packages despite it is relatively young). I think the reason is that it both allows for cross-language projects (If you want to publish a vector drawing program with image algorithm libraries written in C, a GUI done in in Python, and memory-safe media importers written in Rust - it is made for that!). And it runs on top of many larger distributions (I use it on Debian stable and Arch).
In Guix, package definitions are part of the Guix distro and are vetted.
Heard you the first time. I asked you what makes you think that’s the case.
Guix is a smaller distro with (presumably) less maintainers, but it has 2x the packages that Arch has in it’s official repos, and you assume they’re well vetted? AUR has 3x (and a shitload of eyeballs), so it’s probably a reasonable assumption as a comparison, but your post is basically just “trust me bro.”
Guix packages are vetted.
AUR packages aren’t.
And, package definitions in Guix are not shell scripts but highly abstracted functional installers that use the respective build tools of software packages. This makes them much easier to review - and quicker to write, in many cases.
Guix is also fully reproducible, and has the goal to provide safe distributely built software. (It gets significant hate from tech companies for requiring GPL licenses for the core distro, and thus not supporting binary code without source code).
As the case of the xz-utils package shows, this does not prevent that a widely used project is taken over by malicious actors, and stealthily malware becomes inserted. But the effort to do this is much larger, since this needs write access to the software’s source code.
And no, I don’t think Guix is the magical silver bullet for software security. But it is much better than unvetted shell scripts in AUR.
And of course, Guix has disadvantages, too. The biggest disadvantage is IMO that it is really slower than Arch’s pacman, because Guix - being based on source packages - sometimes builds stuff from source. But I think this does not matter so much if one is using it for ten or twelve extra packages. (It also got a lot faster with moving to Codeberg.)
I’ve seen AUR warned against often, also by Arch team members.
I never thought it was a huge deal, but apparently anything that can be attacked will be attacked nowadays.This is what happens when a shit load of packages that just sit around basically unmaintained are allowed to sit around.
Maybe injecting the infections made it look like they were maintained? 😋
I start to wonder if we need something sitting between extra and aur, few more trusted maintainers and well secured update process that’s more than the aur Wild West
Also, some sort of yay hook to do some scanning for suspicious diffs and warning or skipping those packages…
I don’t want / need a system where I can blindly update everything, but something to help me avoid having to visually check every package diff would be nice
Yes that would be nice, but I’m not sure that is possible.
Their first option is possible for sure. Just something like the AUR, but that you need a proven record (either on the AUR or on something else) to post. That shouldn’t be too hard.
I feel like this could be a use for LLMs that isn’t slop. It’s not going to catch everything of course but I imagine it would be a whole lot better than nothing
https://aur.archlinux.org/ warns you about it
Yeah if your machine can be added to a botnet then it will be. Resistance is futile, we are Borg style.
I got a notification about a package that changed the maintainer that looks rather suspicious to me… So i would still be careful…
https://aur.archlinux.org/account/svantehedlund
That user doesn’t seem to be blocked… So there might still be more going on.
Very normal looking. /s
A couple of weeks ago, some dingbat of an AUR admin orphaned a package of mine, ignoring the comment I left on it and my post to the mailing list.
Even though this package, to my knowledge, didn’t end up being attacked, I wonder if this was a potential precursor to the recent attack…
To answer your question, generally yes the package maintainer is the one who maintains the package for the current version of the distro, even if upstream is unchanged. If a package is no longer compatible and no one is making it compatible, then yes it’s unmaintained and should be removed.
It wasn’t removed, it was marked as orphaned, which means anyone can take over and mess with it, lowering the bar for supply chain attacks.
If another user had said “I can take care of this long-term, gimme”, I’d had handed it over. Instead, some self-important dingbat with too many privileges decided to mass-mark all packages with an “outdated” flag beyond a certain age as orphaned, then ignored my mailing list post.
For what it’s worth, a distro package maintainer’s inability to update a package to a newer upstream version does not necessarily lead to a package being removed. Debian and Ubuntu kept shipping an ancient version of
freetdssometime in the mid-2010s and the package maintainer was incommunicado.
We’re currently at 1621.
I’m still missing any sort of in-depth info about all this.
Start here. https://bbs.archlinux.org/viewtopic.php?id=313892
AUR, the Arch User Repository is under an attack. The attack vector is any orphaned package that doesn’t have a current maintainer. Those packages are being taken over by a malicious group. https://redlib.catsarch.com/r/archlinux/comments/1u3tn4e/tons_of_new_infected_aur_packages_were_just/ If a package maintainer quits/leaves/abandons a project, anybody can take control of the package if there’s been no maintainer for a certain period of time. What we’re learning now is that this process could be automated and done en masse. They’re modifying PKGBUILD files to use a java script installer like npm, bun, yarn, nodejs to shove malware onto a system. So if you have a package that’s marked as infected and you’ve updated your PC using an AUR helper like yay or paru during this time without checking the PKGBUILD you could be in trouble.
What users are advised to do is not update any AUR packages until otherwise noted. Scan your systems for any packages where the PKGBUILD reports installing an atomic-lockfile, js-digest file through npm, bun, nodejs, yarn and the like. Delete those packages.
The number of infected packages has gone from 400 to 600 to 1500 in a matter of hours last night. The AUR team has been on top of it almost the moment it got recognized. The AUR has well over 100,000 packages. Last night another user ran some numbers and at the time 718 infected packages had no users at all. The most popular package is an old Gnome dependency libgdata that was dropped years ago but could still be on systems. There’s a lot of old packages using ancient python2 deps that look to be infected as well. https://redlib.catsarch.com/r/archlinux/comments/1u4fzea/according_to_pkgstats_these_are_the_most_popular/ list of infected packages https://md.archlinux.org/s/SxbqukK6IA Seems like this was caught because old maintainers started getting emails about package updates to old projects they were on. Those OGs sprung into action.
Thanks. The forum thread’s beginning suggests a concerted effort around adding the line
npm install atomic-lockfileto repos.Searching for that I quickly found this: https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency and related articles.
Then it seems to change to ‘bun’ and ‘js-digest’:
bun add figures debug js-digestApparently both atomic-lockfile and js-digest are upstream npm/javascript packages that have been infected with datamining malware.
BTW, admins reported as of 12h ago it’s all cleaned up.
Wouldn’t even suprise me if they just did it fo the lulz.
They got hacked.
Use Debian. /s
I meant something I can read.
They got hacked.
I don’t think so.
I mean
Like…
Yes?
Yes, that’s what happened. That is the correct word for it.
Attackers exploited vulnerabilities in a system in order to run code on other people’s machines
same
What to do if I found a package I installed to be in that list? libgdata to be specific?
Edit: Seems that the libgdata package was last installed on March 05.
Have a check if you updated it recently (PKGBUILD history, about June 10-12). If not you’re fine.
If:
- Rotate all credentials — browser passwords, SSH keys, API tokens, and cloud access keys
- Scan for suspicious processes masquerading as kernel threads using tools like rkhunter or chkrootkit (E: It’s supposed to be an eBPF rootkit)
Personally I would reset everything if I got anything, to kill both any infection and my paranoia. Then reset credentials.
Was it installed from the aur? If not, you’re fine
Probably reinstall (all is supposed to be fixed as of over 12h ago). This time check the PKGBUILD and also whichever (git) repo the software is pulled from.
See if infected versions of npm packages atomic-lockfile and js-digest are installed.
Does anyone know if the NixOS packages are safer from these types of attacks? As far as I know many packages are missing maintainers.
I read a reddit thread about this.
Basically they are significantly safer because the review process is tedious and the PRs take ages to get reviewed. More over the read-only nature of the nix store make most of those techniques useless. You cannnot just take over packages the AUR way.
Moreover, if you use third party nix flakes, you are still safer because they are tied to a specific github repo, so if it gets forked by malicious actor you won’t get that update.
However you are still prone to upstream malware. That is nixpkgs probably won’t add malware but it could be there before packaging.
Yesterday that was 400 packages, now it’s 1500.
Tomorrow 3000 ?
I use devuan btw
“I use arch btw” lmao
I use AUR BTW!
Arch and AUR are not really the same. To be fair AUR is the fanfiction version that fits inside the story. But you have to purposely work to use it. So it’s not Arch that was compromised.
IsIs it really all that difficult to use these popular coding and browsing tools such as Heroic Launcher, Visual Studio Code and Brave within Arch Linuxes like CachyOS?
Last time I touched an Archy Linux, I don’t recall it being difficult for some of the things on that list. And it still comes from a central store of apps reminiscent of the Microsoft Store for example…
To use the AUR, you have to install a AUR Helper https://wiki.archlinux.org/title/AUR_helpers
They are not just “click and go”. They require a dedicated effort. AND when you’re done, using them requires a specific command. So in short, it’s not pacman and it’s not Arch, the AUR is a special choice
Haven’t seen an arch fuckup like this since they switched to signed packages.
This is not ArchLinux’ fuckup. The AUR’s popularity exploded after certain Arch-based distros (and software) decided to treat the AUR as an additional software repository, even part of package management, and automate the process of installation. Which also slows the process of discovering the malware. And makes panicky users wave their arms.
May I remind everyone of Arch core principles and statements wrt AUR - several quotes from their wiki:
Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric:
- The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible.
- It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.
The Arch User Repository (AUR) is a community-driven repository for Arch Linux users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with makepkg and then install it via pacman.
Note how the crucial PKGBUILD is mentioned in the first sentence, and dozens of times in the article that follows.
Warning
AUR helpers are not supported by Arch Linux. You should become familiar with the manual build process in order to be prepared to troubleshoot problems.The AUR even includes PGP signing; not perfect, but a useful additional step. But, alas, many AUR helpers include “skip PGP check”.
Archlinux devs, maintainers and users have been saying this for over a decade, and warning against using the AUR in such ways. But short of shutting the whole thing down, what can they do? The few things that can reasonably be done I’m sure are being implemented right now.
Warning AUR helpers are not supported by Arch Linux. You should become familiar with the manual build process in order to be prepared to troubleshoot problems.
Nothing in that warning is related to security
Ah now I read this far. Unfortunate, if easy to use Archy distros are un-Archy due to this political dispute that goes undisclosed.
It doesn’t sound like their victims are panicky users, though. Sounds like their normal computer users, the kind of person who would typically want use Windows instead. The kind of people who are, and should be safe to remain, totally agnostic to these internal political divides.
“Political”?! 🤪
As in “office politics” or “workplace politics,” yes
I wouldn’t really categorise it as a fuckup. These are unofficial packages from the AUR. You should trust them as much as random install scripts from a no-name website or git repo.
It’s no arch fuckup. The AUR is not an arch linux redponsibility and has always been “untrusted” - you should always verify what you’re downloading and building.
Problem is that bazzite and cachy are arch-based, but targeted at a group of people that arch doesn’t target. So you have users that just blindly download scripts from the AUR without doing proper verification.
This is more the fault of those distros and AUR helpers than arch.
I thought bazzite was based on an atomic version of fedora?
it is
Yep. There’s no AUR for bazzite since it’s based on fedora immutable, unless I’m mistaken and there’s a way to do so anyway somehow. Still, bazzite and AUR do not go hand in hand AFAIK as it’s meant to be an immutable system.
