Arch Linux Disables AUR Package Adoption Amid Malware Surge
The Arch Linux DevOps team has halted the adoption of orphaned packages in the Arch User Repository due to a wave of malicious attacks. Attackers recently created accounts to inject remote-access trojans into legitimate software, prompting this security measure. This follows a previous suspension of new account registrations, as minor restrictions proved ineffective against the coordinated campaign targeting user systems.
No one defence is likely to suffice.
- WD-42
I’ve been using arch for nearly 2 decades at this point. It’s amazing that the AUR went this long without any serious attacks.
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?
- vlovich123
> The project had suspended new account registration in June. That followed a campaign in which an attacker or attackers created new accounts to adopt orphaned packages and push malicious updates to them that would install malware on user systems. AUR registration was reopened on July 13 after the DevOps team added some minor, and apparently ineffective, restrictions on creating new accounts.
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.
- delecti
That title had me worried, but the reality seems quite reasonable.
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.
- uticus
From the actual announcement:
> ...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.
- uticus
WRT package vulns, I'm surprised there's not more technical theory out there. We have plenty of theory around algorithm design, but so far I haven't heard much about inspecting and improving control of dependencies in source - apart from conflict and version management.
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".
- antibarbarus
Ever since the first wave of attacks it was clear this wasn’t a passing thing, and would return unless the AUR fundamentally changed. They introduced... email verification, then hoped for the best. In a sense it’s good that this has happened as I think it will help the team understand it can’t go on like this.
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.
- zache6
I haven't been updating AUR packages since the initial incident. Thankfully hadn't updated for a week prior to it. Tonight I'll be uninstalling all the AUR packages I possibly can.
- tim-projects
I added a git repo to AUR last year. It was super easy with basically no checks of any kind. Once these reports came out recently, I went through and deleted every AUR package that I could.