Arch Linux disables AUR package adoption
lwn.net
lwn.net
It’s a different world now. I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
It's definitely an outlier, but more in terms of being something that doesn't really exist anywhere else, so of course the security model for it will also be an outlier. That's not an excuse for any security issues, but it's not like Arch doesn't have official repos with maintainers who are just as diligent as any other distro. They just also happen to provide a public git server that people can publish packages to with a UI for seeing some of the package metadata; people could just as easily write toolling to automate package management where it looks for a GitHub repo instead of an AUR one to fetch the build files.
And no, "people using one Linux distro can opt in to possibly getting pwned by each other by making use of a third-party software depot" does not reflect upon the entirety of the Linux world.
And unfortunately that’s how arch is mainly marketed by its users. “Arch has the latest everything, if it’s not in the repos it’s on AUR” is one of the standard selling points.
Of course that speaks to how people use linux insecurely not how Linux is insecure.
Maybe most users just ignore that and always answer yes without inspecting it. I don't know. But the wiki for the AUR and Readmes for many of these tools have warning banners telling you not to blindly trust AUR packages.
Nonetheless, the full tray is just one yay away, which also speaks git.
How you use such tools is totally up to you.
So far I've been unaffected by the AUR hickups, running Cachy for about 2 years now.
But I've been always wary about the AUR, trying to minimize its use. Even in the phase where I used pure Arch for several years. It tends to get messy. So less AUR is less mess.
significantly so. Windows has a coherent story when it comes to permissions and access. Differentiated out access controls, least privilege, UAC, mandatory integrity control and all configured out of the box.
Without AppArmor or SElinux correctly configured, which it isn't on most desktop distributions in the linux world most of your apps can still read anything, there's little sandboxing. The NT Kernel was designed with an object model in mind so you always had the abilities to have rich descriptions and policies for whatever you're handling where all of that is bolted on unix systems after the fact.
Yet that doesn't seem to matter much for stealer malware.
Of course Windows regardless has taken the brunt of the attacks because it ran virtually every desktop machine in the world so people go after users anyway. Desktop Linux systems where never economically interesting for malware. But now that they have gained a modicum of traction they're going to get the exact same treatment, hence this thread.
Microsoft doesn't advertise it much but they do have the advantage of controlling their build environments, software is signed etc. A system like the AUR where you pull in unsigned packages from anonymous people with so many arch users relying on it is not going to be easy to address. It lived on security through obscurity.
It's not meaningfully reduced. The stealer just has to call CryptUnprotectData before uploading it. It's not even like it will show a suspicious prompt to the user, without having to do anything extra the stealer can silently decrypt it.
I agree with the rest of the post though.
Maybe I’m a minority, but the tools are very mature and easy to use IMO. In windows land people are still installing random EXEs, that’s the reality.
There are more ways to attack people than third party software depos.
That is never how the AUR was supposed to work. Updates were intended to be a manual process where the user reviewed changes to the PKGBUILD.
This has absolutely not ever been the case.
EDIT: Rereading, maybe it's that other kind of "hacker"...
I think it was. Eg: on most russian warez forums in the 2000s, it was a bannable offense to crack russian-authored software.
That being said, I think the particular example you provided is kind of weak. It's my understanding that the behavior you speak of was driven primarily by the Russian government's unofficial policy of ignoring cybercrimes committed by their citizens so long as the targets were not domestic. They were ensuring their ability to continue operation by banning discussion of targeting Russians. This is how groups like the Russian Business Network have been able to flourish.
If 1:10,000 people is an axe murderer, when your community reaches 20,000 people... You have to create an axe-murderer-captcha.
What’s more likely is the effort required for large scale attacks is easier now than ever thanks to LLMs.
I also believe this is the main reason why web took off: effortless distribution and sandboxing.
It's weird that installing software is weird to you.
My assumption is these aren't so much hackers, as modern day script kiddies armed with LLMs and too much free time.
There have been a variety of cultural elements to people doing security research / hacking on their own systems / etc.
There has never been "honor" among criminals looking to use technology to steal money or steal things that can be converted to money.
The answer is: Russians
Source: I'm the guy that built the antimiasma mitigation tool [1] and tracked their malware campaign iterations very closely.
Set LANG to ru_RU.* and the malware implant stops spreading itself, as with all APT28/29 malware.
[1] https://github.com/cookiengineer/antimiasma
[2] https://cookie.engineer/projects/cyber-defense/antimiasma.ht...
Incorrect. ASCII is 0000-007F and the BMP is 0000-FFFF
That is why I linked my blogposts, the tool, and the whitepaper that I published about it. You have to read it first to come to your own conclusions.
If you come to conclusions without reading either of it, there's no point in arguing with you because you made up your mind anyways, and are not interested in learning about malware reversing :)
Now it got more popular but still low entry attack.
> It’s a different world now. I can’t help but feel there used to be honor among hackers. You didn’t go after your own. What kind of jerk would attack Arch Linux?
Not sure why hacker would waste their time fiddling with Arch instead of hacking stuff, everything that they need can run just fine on any of the Debian derivatives.
Disabling AUR package adoptions has been like the #1 thing recommended. While it's a positive step, it's not good news they literally tried everything else first. This doesn't speak well to the security headspace of the Arch maintainers.
Fedora Copr, FreeBSD Ports, are all of a similar idea. Where Arch screws up is in allowing people to take over abandoned PKGBUILDS instead of making them create new ones.
This can happen to Ubuntu with the PPA's too if someone were to gain control over, say, the Nvidia PPA for drivers. It's happening almost daily with NPM and Github. Supply chain attacks are serious and the Arch devs do warn people about this right off the bat. You don't go installing from the AUR without understanding the risks.
Yes, lots of people thought disabling package adoption is/was a good idea. It seems quite likely that the Arch DevOps team also could have come up with that one, and they certainly wouldn't have missed all of the people telling them to do so.
It seems to me that disabling package adoption is not a desirable thing to do in general, and can only be used as a stopgap response to an emergency, which seems to be what is happening right now.
"just disable adoption" certainly can't be a long-term solution: Without adoption, the AUR will slowly fade away as orphaning a package would be permanent. Maybe the idea is to have some sort of approval process to filter adoption requests? In that case the AUR just dies instantly as that would effectively be another official repo with all of the issues that that would bring.
This - they tried this first even though it’s pretty obvious this is an ineffective mechanism to fight security issues around adopting orphaned packages.
“Security headspace” means treating security seriously and acting appropriately and correctly with appropriate urgency. This whole saga they were slow to respond, they took days to actually stop the ongoing attack, and have tried everything else other than stopping adoption of orphaned packages. This should have been the FIRST thing done and only once you have a solid idea on how to reenable then you allow it. And even then I’m not sure orphaned packages are ever suitable for adoption - if you want to take over for an abandoned project, you start your own alias and try to convince all downstream dependencies to change where they point. This makes it adoption by the community which is slow and takes time and won’t be as trivial to convert into a mass scale cyber attack.
That everyone here is “but adoption is required for AUR” makes it clear there’s very limited experience and research on how other package managers don’t have this embarrassing failure (both OS and language ones like node and Cargo which have to deal with far more sophisticated attacks) and this is the way - you don’t allow identity laundering. They are all susceptible to identity laundering by just buying the project (assuming the maintainer is open to selling their keys) but that’s harder to scale by a script kiddie and requires a more sophisticated form of action.
Do you have a solution to ever reenabling package adoptions? It's pretty much a must have feature for this to exist long term, at least in the AUR's current state where its a repo your not supposed to auto install from but pretty much all users do.
Really disabling adoptions is probably step 1 to just EOLing the whole thing.
The AUR by definition isn't to be trusted. That's what the official repos are for, you're supposed to read what the package install scripts are doing.
That's what they should do. The AUR has been a giant fuckup since the beginning, which is especially outrageous seeing as they had the perfect template for it with Gentoo's GURU.
If you want to convince someone “my copy of foo is much better maintained than foo-legacy” you are free to go downstream dependency by downstream dependency and convincing a switch / convincing end users to install yours. You can even have hints to users “hey this package looks to be abandoned - did you mean X”
1. Lose money burning tokens in all of this stuff. 2. Lose reputation when some malware eventually makes it through
I assumed the goal was to reduce usage of AUR, they've actually remove the ability to adopt (take ownership of) orphaned packages. I'm sure there are legitimate uses of that functionality, but it also seems like a pretty big avenue for abuse.
To avoid package name pollution, e.g. having package foo, foo-newpackage, foo-newpackage-updated, etc. each by a new maintainer as the priors get abandoned.
https://wiki.archlinux.org/title/Unofficial_user_repositorie...
The problem with user repos vs the AUR is that you're trusting the maintainer behind them instead of inspecting the PKGBUILD and fetched sources yourself.
The entire problem is that people weren't inspecting PKGBUILDs. At least with user repositories, you have someone who can build a reputation for trustworthy packages. There's a reason why every other distro does user repos.
Which is probably the best choice, unfortunately.
> ...package adoption is currently disabled while we are handling the situation.
Sounds much more like the temporary pause, than the much less temporary-sounding "has been disabled" from the OP.
Seems like instead of big-O notation, we could have a "reach index" - how far does the top-level code need to reach, to be effective? Top-level -> Userland lib 1 -> Userland lib 2 -> Kernel, would be a reach level "4" - not the simplest, but much simpler to inspect and securely build than reach level "20".
The world of exploits and malware thanks you for your service.
> Thankfully hadn't updated for a week prior to it.
Chances are this started more than a week before it was discovered.
> Tonight I'll be uninstalling all the AUR packages I possibly can.
Instead, you could just use the AUR mindfully in terms of which packages you install and review the code.
I’d hate to see an AUR that’s a walled garden, and I’m not sure what an Arch without the AUR would look like. But something in between will need to be invented.
I use FresBSD, where I rarely run in to this problem, that something is missing from ports.
However, it is a common occurrence in Arch. Which is a shame, because it’s otherwise a fine operating system.
If users aren't supposed to trust anything from the AUR, then they will start to use LLMs to scan PKGBUILDs for them. But at that point, why not let the LLM loose directly on the upstream repo and build+install the package from source?
That being said, didn't know there's a RISC V effort as well now, so TIL.
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=batte...
(honestly I think the way that arch packages work is really nice compared to most other distros: you can almost copy and paste the README of a project into one and have a package)
Here's the most complicated one I found, building a browser:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=flowf...
The main risk, if you're reading them, is typosquatting and hiding the malicious code in what the project downloads.
Uh sorry what? Can you point to a PKGBUILD that is indeed this complex?
See also, the -o- emoticon: https://youtu.be/M1si1y5lvkk&t=1902s
Favorable environment of Linux distros is an initial phase of technology. This state is gone for years now, AI is just making it evident. Adapt or become obsolete.
Security concerns about supply chain attacks in the AUR (well known to be extremely insecure well before LLMs got popular) isn’t “killing” Arch let alone “killing Linux distributions”, plural.
The owners of AUR would do this for all packages they host so the inconvenience does not fall on other people. AUR has to take responsibility over the security of what they offer.
So you have to scan an arbitrary bash script and determine if it pulls malware, or build the package server side in a sandbox and scan it (and some AUR scripts wrap proprietary software blobs the user is supposed to provide e.g. MATLAB, which makes those impossible to build server side). It's a very big extra layer that malware deployments can hide in.
The obvious-but-hard solution to this, as well as certain other attacks like the xz incident, is a chain of trust. Every line of code in every package should be cryptographically attributable to an individual or an organization, ideally associated with a government-issued ID. Git commits without a real name and a cryptographic signature should be taboo. Nobody should be running or distributing software that they don't know who made.
It wouldn't be perfect - Russia could still attack the AUR, for whatever reason - but the current situation is extremely laissez-faire to the point of being untenable.
Every time Apple's App Store policies come up, it gets criticized by hackers for various good and bad reasons, but this is exactly the problem they're trying to solve, however imperfectly.
In Open Source, we're quite focused on copyright: the concern that someone's honest work gets stolen or appropriated without whatever recognition, attribution or compensation is laid out in the license. But this is the reverse problem: Lack of attribution, and therefore traceability.
So what would that take? What would we lose?
You'd lose the ability to work on and distribute software not approved by your and various other governments. For example, if the UK makes BitTorrent illegal, what happens to you when you've attached your identity to your torrent client when you try to enter the UK (or already live there)?
Security must be solved without removing anonymity.