RE: https://infosec.exchange/@ifin/116735279416101129

I'm trying to understand the details of AUR processes for submitting PKGBUILDs. In other words, how exactly did this happen? arojas submitted hundreds of changes to PKGBUILD or related files. And they were just...accepted? What am I missing?

Edit: What I missed was this was pure impersonation. The maintainer is fine, but the process was vulnerable to spoofing.

@mttaggart AUR packages are completely community-maintained. The idea of changes being accepted means the community maintainer pushed the changes. If an AUR package doesn't have a maintainer, you can essentially just volunteer to be the maintainer for the package. If the maintainer of an AUR package goes inactive, you can flag it and after a period of time (14 days, IIRC), become the maintainer.
@r0k So no vetting for adoption then? Just volunteer?
@mttaggart correct. and oddities wouldn't be likely to be noticed unless the small corner of the community who cares about the specific package is paying attention.

@r0k Thank you for the explanation!

Seems like, for any given abandoned package, the impact would be minimal. But across all abandoned packages, a persistent attacker could do quite a lot of damage over time.

@mttaggart @r0k
I think this was build-time malware, so not that long.

@r0k @mttaggart

If I understand correctly, as soon as an AUR doesn't have a maintainer anymore (because the maintainer removes themselves), the AUR can be adopted by someone else.

It looks like it happened e.g. for stripe-cli:

https://aur.archlinux.org/packages/stripe-cli

(Very short timeline between the maintainer removing themselves and the package being adopted + malwarized.)

Note: the hostile commits were already removed from the AUR git repo for that package.

AUR (en) - stripe-cli

@mttaggart @r0k Jup. More than one package I’ve orphaned from lack of spoons got adopted within minutes. So there’s some people who automate the adoption process. E.g. https://aur.archlinux.org/packages?O=0&SeB=m&K=xiota&outdated=&SB=p&SO=d&PP=50&submit=Go (This is not a judgement on that user, just an example)
AUR (en) - Packages

@mttaggart Antonio Rojas is a member of Arch Linux and a year-long package maintainer of the distribution (e.g. for all of KDE).

Antonio often drops larger amounts of packages to the AUR and therefore is the last committer.
The bot infecting packages in the AUR impersonated/reused the last committer. It's trivial to do with git.

I know this is not directly obvious, but please correct previous statements about this (also made elsewhere). 🙏

@dvzrv @mttaggart Yes, many thanks for your posts but please correct this !
@joost_rekveld @dvzrv Thank you, it's been fixed.
@mttaggart AUR packages are "at your own risk" and you are supposed to review the build packages. That's why they are not in the main repos, they are not supposed to be implicitly trusted or auto-updated/installed.

Having said that - I am with you, I expected
some level of vetting to get them listed in the AUR itself.

#AUR #ArchLinux

@mttaggart Being able to "adopt" hundreds of orphaned packages in one fell swoop feels like a major attack vector that could have significant friction added without getting in the way of genuine folk.

And maybe the GPG web of trust could be extended to the AUR, and established contributors grandfathered into it - so when you install an AUR package you get a warning if there's an untrusted maintainer? IIRC there's no key signing in AUR right now because there are no packages.

But... how to know whether that one person who wants to adopt that one package is legit? If there was some sort of well-known probation threshold like the 10 commits people have been discussing on aur-general, a malicious person could simply Jia Tan their way through that?!