multiple malicious AUR updates

tridra · 2026-06-19 17:10:27

dasrubbellos wrote:

Hyper-focusing on the PKGBUILD is your prerogative, of course, but you're ignoring every other security and trust principle around it because of a singular method you think works for you.

It works for me because I have zero trust in whoever is the maintainer of a PKGBUILD. I don't have to trust them in order to use a PKGBUILD. And I don't even know who they are. For all I know, they could be the next Jia Tan. If we start with this premise, a maintainer change makes no difference.

This focus on maintainer change is based on the assumption that the next attacks are going to be similar, but we shouldn't assume that every attack is going to go after the lowest hanging fruit and they'll deploy the attack as soon as they can. And this attack also exposed another problem that attackers are going to exploit: many people don't read PKGBUILDs. Now attackers can attempt to adopt more popular packages, even if it requires more effort, because it might be worth the effort. So, if anything, now it's even more important to read the PKGBUILD, regardless of whether the maintainer has changed or not.

dasrubbellos · 2026-06-20 02:09:55

There is no "focus on maintainer change". This is about looking at the metadata in addition to the data for (structural) risk assessments.

loqs · 2026-06-20 05:50:53

dasrubbellos wrote:

This is about looking at the metadata in addition to the data for (structural) risk assessments.

Can you elaborate on what you mean by structural risk and how the metadata aids in that assessment?

cfr · 2026-06-20 07:00:04

seth wrote:

Probably in the little scripts one or some other time somebody missed some news.
#!/bin/sh
export LC_ALL=C
THIS_MONTH="$(date +'%b %Y')"
LAST_MONTH="$(date +'%b %Y' -d -1month)"
curl -sL 'https://archlinux.org/feeds/news/' | tr '\n' ' ' | \
xmlstarlet sel -T -t -m "//rss/channel/item[contains(string(pubDate), '$LAST_MONTH') or contains(string(pubDate), '$THIS_MONTH')]" \
                        -o $'\n\e[33m' -v pubDate -o $'\n\e[0;1m' -v title -o $'\e[0m' -v description -o $'\n\n────────────────\n' |\
sed $'s/<p>/\\n\\n/g; s/<h.>/\\n\\n\e[1;34m/g; s%</$h.\|b\|em\|strong\|pre\|code$>%\e[0m%g;
    s/<li>/\\n· /g;
    s/<$code\|pre$>/\e[1;32m/g;
    s/<$strong\|em$>/\e[1m/g;
    s/&gt;/>/g; s/&lt;/</g; s/<[^>]*>//g' | fold -sw 100
It just gets the rss feed, filters out the recent months and then turns the html into ansi escape sequences.
...
Understanding that you don't understand most things is the entrance to the path of wisdom. I think I told that some greek dude like 2500 years ago…
The recent attacks have not been very sophisticated, the introduction of npm to those packages is completely nonsensical and would probably have stalled you and the most recent stunt to obfuscate code basically yells "hey look at me, I'm doing something shady"

Thanks.

[Not quite Socrates' position ... ]

seth · 2026-06-20 07:09:21

Things might have gotten conflated in this megathread and across the wider discussion.

Various people argue that reading the PKGBUILD is unrealistic/too much work/etc and that there should be some form of trust system around the AUR PGKBUILD maintainers ("can please somebody else take responsibility for my actions") and have pointed at the orphaning process and suggested that there should be warnings when the maintainer changes. This gets pushed back because limiting the AUR to a set of trusted users defeats the point of the AUR, crowd/voting/heuristic based trust systems can easily be gamed and also the takeover of mostly stale orphans is an anecdotal incident an by no means the only way how you can end up with malicious code.

There's in this light also the (at times clearly expressed) idea that there should be unprompted warnings (implementation technicalities aside) when the maintainer changes, as trigger for heightened sensitivity and with the implication to otherwise run AUR updates on autopilot (which is, generally out of unawareness, the unfortunate defacto status quo for many users and the reason we're having all those discussions now)

I'm gonna be very blunt about it: this approach is imbecile and based on a bunch of false premises to justify laziness.
If that's your idea of the AUR, stop using it. If that means you'd rather use Ubuntu then that is exactly what you're better off to do.
You're not guaranteed to find every super-sophisticated malicious change but you have to give your brain a fighting chance by at least looking at it.

If however the AUR allows to push commits from authors other than the maintainer (something I'm frankly not eager to test) such disparity *can* help to determine at which point an imposter became active what *can* be useful for a post mortem (eg. if malicious action is detected after the imposter had already been active for months, what has however not been the case in the (few) instances of the recent events that I've seen) but (transparent) changes in maintainership must never be used for triage

The triage starts with the patch itself - if that looks already sketchy, it's reasonable to wanna look where it's actually coming from.

Trilby · 2026-06-20 14:20:00

duaner wrote:

... I wonder if it would help to have more specifics a newbie could look for, spelled out under "Verify the PKGBUILD" ... Is there a short list somewhere of ways people have tried to sneak malware into AUR packages before

I like and support the first part of that. But the second part is really the wrong approach. The second part leads to numbers one, two, and three on this list of problems. (Though arguably the whole goal here is number 5 on that list).

The goal is not to rule out all the known ways a PKGBUILD could be "bad" by ensuring it is not doing a set of bad things. The goal is for users to be confident that it is good because they understand all the things that the PKGBUILD is doing.

There are infinitely many ways to make a problematic AUR package - but a much much more limited number of ways of making a proper package.

The best strategy is to review the PKGBUILD (and associated files) and recognize what is done right. Anything you don't understand and recognize as good / proper should be investigated until you do understand it and are confident it is proper or - alternatively - discarded and not used. There are resources for this goal - and perhaps they could be expanded. But these resources are on how PKGBUILDs should be written and how AUR packages should be submitted - a list of ways it has been done wrong is of no real value for this goal.

In contrast, a list of common mistakes can be a useful educational tool - but that is for a different educational goal. "Common mistakes to avoid" are good for well-meaning actors striving to learn the proper process. "Common attacks previously attempted" is of quite limited value in avoiding future attacks (limited to the point that such efforts provide a false sense of security that is not worth the effort needed to make such lists).

Note that there is one flavor of question that we almost never see on these forums despite having a section for it and despite it being a valuable and worthwhile question. That flavor of question would be "I just got this PKGBUILD from the AUR. I understand most of what it is doing, but I don't understand what's happening on lines 14-16. Can someone clarify what these commands do so I can feel confident using this PKGBUILD." But also note that this is a very different question from the similarly motivated but intellectually lazy "Hey bros, is this PKGBUILD safe?"

Last edited by Trilby (2026-06-20 14:25:38)

cfr · 2026-06-20 16:16:46

Trilby wrote:

The best strategy is to review the PKGBUILD (and associated files) and recognize what is done right. Anything you don't understand and recognize as good / proper should be investigated until you do understand it and are confident it is proper or - alternatively - discarded and not used. There are resources for this goal - and perhaps they could be expanded. But these resources are on how PKGBUILDs should be written and how AUR packages should be submitted - a list of ways it has been done wrong is of no real value for this goal.
In contrast, a list of common mistakes can be a useful educational tool - but that is for a different educational goal. "Common mistakes to avoid" are good for well-meaning actors striving to learn the proper process. "Common attacks previously attempted" is of quite limited value in avoiding future attacks (limited to the point that such efforts provide a false sense of security that is not worth the effort needed to make such lists).

That's definitely true, especially since any such list is equally available to attackers looking to optimise an attack's impact.

However, one or two specific examples of past attacks with an explanation of how a user could have spotted problems by reviewing the project files would be useful. This is not so much because the specific things to look for would be useful - as you say, that would just give a false sense of security. But a concrete example is probably more effective in raising awareness than an abstract statement about the need to vet AUR packages.

tridra · 2026-06-20 17:43:00

Note that there is one flavor of question that we almost never see on these forums despite having a section for it and despite it being a valuable and worthwhile question. That flavor of question would be "I just got this PKGBUILD from the AUR. I understand most of what it is doing, but I don't understand what's happening on lines 14-16. Can someone clarify what these commands do so I can feel confident using this PKGBUILD." But also note that this is a very different question from the similarly motivated but intellectually lazy "Hey bros, is this PKGBUILD safe?"

It's even worse than that. I've seen people posting LLM outputs where they asked "is this PKGBUILD safe" instead of asking the LLM to explain to them line by line what the PKGBUILD does.

seth · 2026-06-20 18:51:55

@cfr, anything you don't understand or don't expect

There's a constant to all attacks and that's that the maliciou… asshole needs to sideload data that is under his control.
Wrt the AUR there're two main ways to achieve that:
1. just blatantly downloading it from the internet
2. brazenly ship it w/ the AUR data

For (1) this might be
a) entries in the source array that are not the supposedly packaged upstream or
b) remote access during any of the prepare/package/build… functions (what is not supposed to happen) - "why is there a curl/wget/rsync/… in the prepare() function??"

For (2) the asshole has to prevent you from seeing it, so adding "evil_script.sh" to the AUR files isn't an option.
But one could steganographically hide it in something that looks valuable, eg. by adding a translation of the documentation into a made up language nobody speaks, like Chinese.
Except it's not documentation and also not Chinese, it's gibberish in the Chinese UTF8 block which can be cesar-chiffred into ascii and the it's a malicious python script… hold on, wait a second…
How many people???
…
DAMMIT!!
Spoiled by my own ignorance again!

Ok, new plan: the asshole kindly adds a hi-resolution icon for the program.
Did you know that many image formats have comment fields where you can add (in doubt) unlimited amounts of random text? Well, now you know.

Any of these approaches introduces a new problem: the payload has to be decoded and moved into a target location:
* What does this weird sed script do?? Why does it write into one of the files of the upstream sources?
* Why is this icon used somehow with a variable? And why does this variable expand to /etc/systemd/system/multi-user.target.wants/lennartstuff_dont_touch.service ??

Speaking of target locations, the asshole could try to only infect the build system by accessing an absolute path.
Forgetting ${pkgdir} or accessing $HOME in the package() function can just be a genuine mistake, but it can also be an attack that doesn't leave any traces in the generated package.

As Trilby pointed out, there're a million more ways to be evil, but they all will have to do something weird you didn't expect to see there.
An inherent benefit of reviewing every PKGBUILD (next to shielding you from malware) is that you'll build up an expectation for what they should look like (because 99.99% + ε are gonna be benign)

Wrt concrete examples, the prominent one just added npm to the dependencies out of nowhere and npm is notoriously abused for malware distribution.
It frankly doesn't get more obvious than that - and that's why examples of the past are bad.
https://imgs.xkcd.com/comics/password_strength_2x.png makes a very good point but ironically correcthorsebatterystaple is now one of the worst passwords.

Your homework, should you accept it, is to put on a black hat (seriously) and come up with your own strategy to sneak some malware into a package.
This post will be forgotten in 5… 4… 3…

loqs · 2026-06-20 19:33:42

Listing some examples of things that should not be in a PKGBUILD and why such as no `sudo` use or using `sysusers.d` instead of `useradd` akin to anti patterns in programming could be useful.

Last edited by loqs (2026-06-20 19:34:14)

Trilby · 2026-06-20 20:26:50

Okay then, I'll start.

Things that generally should not be in PKGBUILDS:
- Aardvarks
- Amputees
- Apples
- Avocados

Hmm, that's just the A's and quite incomplete. Pick up any dictionary and flip to any page - the odds are every word on that page is something that should not be in a PKGBUILD.

The facetiousness here is purposeful: again, a list of things that well-meaning PKGBUILD authors might insert into one is practical to make. You gave good examples of sudo and sysusers.d. But again, these examples are useful only for a very different learning objective than prevention of malicious intent. Those with malicious intent generally make some effort to hide what they are doing: they wont use the tactics of a well-meaning but ill-educated PKGBUILD author.

Learning about common mistakes does little to nothing to prepare one for common on-purposes.

Last edited by Trilby (2026-06-20 20:28:02)

tridra · 2026-06-20 21:42:29

And there's no guarantee that many of those commands would be visible anyway. The attacker could hide the payload in a self extracting archive.

loqs · 2026-06-20 22:05:09

tridra wrote:

And there's no guarantee that many of those commands would be visible anyway. The attacker could hide the payload in a self extracting archive.

By that logic nothing should documented as all of Arch's packaging guidelines rely on being able to see the code.

tridra · 2026-06-20 22:33:44

I think it would be more effective to teach people what a safe PKGBUILD looks like and if they see something they weren't expecting, they should investigate it.

Last edited by tridra (2026-06-20 22:34:09)

loqs · 2026-06-20 22:41:28

tridra wrote:

I think it would be more effective to teach people what a safe PKGBUILD looks like and if they see something they weren't expecting, they should investigate it.

More effective than teaching both positive and negative examples?

tridra · 2026-06-20 22:45:38

Who would this be targeted to? I see "how many ways a PKGBUILD can be a vector of attack" as an advanced topic, not aimed at beginners, and no guarantee that an attacker would do any of that anyway.

Last edited by tridra (2026-06-20 22:48:53)

loqs · 2026-06-20 22:49:07

loqs wrote:

Listing some examples of things that should not be in a PKGBUILD and why such as no `sudo` use or using `sysusers.d` instead of `useradd` akin to anti patterns in programming could be useful.

tridra wrote:

Who would this be targeted to? I see "how many ways a PKGBUILD could be exploited" as an advanced topic, not aimed at beginners, and no guarantee that an attacker would do any of that anyway.

How did you get from my comment to "how many ways a PKGBUILD could be exploited"?

tridra · 2026-06-20 22:51:48

I guess it depends on how many examples would be included in this hypothetical guide. I can imagine a lot.

loqs · 2026-06-20 22:58:52

This topic is now becoming a duplicate of https://bbs.archlinux.org/viewtopic.php?id=313924.

tridra · 2026-06-20 23:05:11

I think we went full circle. I feel like we're going back to the discussion of having automated safety checks for common/expected types of attacks. If the intention is to teach specific patterns, might as well automate it if possible and make learning those patterns obsolete.

seth · 2026-06-21 07:33:29

A list of DOs and DONTs for PKGBUILD might help to
* lead to better average quality of the PKGBUILDs in the AUR (ie highlight bad ones by reducing the noise)
* get a sense of what to expect a PKGBUILD to look like

Putting it into context w/ vetting the PKGBUILD risks to make users subconsciously limit their analysis to those elements and then causes the same problem like would heavily advertising tools like traur (or even present an automated score on for the submission) by telling evil people exactly what they'll have to outmaneuver.

I'll also point out that the recent attack has barely violated those standards and could have avoided it completely because it relied on you installing npm and a runtime daemon to fetch the malware from there and depending on a repo package and providing some kind of service/cronjob are generally perfectly reasonable parts of a package.

vetting means validation and verification means to *understand*
a) what something does/tries to do
b) whether it does that correctly
and while this should™ be a solvable task for ordinary PKGBUILDs it remains your problem even if you're overtasked by the complexity of *some* aspects of *some* PKGBUILDs

In the latter case trying your luck to learn with google or asking here or on reddit or even an AI for a breakdown are all better options than betting on any kind of metadata (votes, downloads, wAs tHiS An oRpHaN, …)

Lone_Wolf · 2026-06-21 12:22:31

Moderator Note
Please continue in the other thread (only visible for logged in users) linked by loqs in #194 .,

Closing this topic.

Arch Linux

#176 2026-06-19 17:10:27

Re: multiple malicious AUR updates

#177 2026-06-20 02:09:55

Re: multiple malicious AUR updates

#178 2026-06-20 05:50:53

Re: multiple malicious AUR updates

#179 2026-06-20 07:00:04

Re: multiple malicious AUR updates

#180 2026-06-20 07:09:21

Re: multiple malicious AUR updates

#181 2026-06-20 14:20:00

Re: multiple malicious AUR updates

#182 2026-06-20 16:16:46

Re: multiple malicious AUR updates

#183 2026-06-20 17:43:00

Re: multiple malicious AUR updates

#184 2026-06-20 18:51:55

Re: multiple malicious AUR updates

#185 2026-06-20 19:33:42

Re: multiple malicious AUR updates

#186 2026-06-20 20:26:50

Re: multiple malicious AUR updates

#187 2026-06-20 21:42:29

Re: multiple malicious AUR updates

#188 2026-06-20 22:05:09

Re: multiple malicious AUR updates

#189 2026-06-20 22:33:44

Re: multiple malicious AUR updates

#190 2026-06-20 22:41:28

Re: multiple malicious AUR updates

#191 2026-06-20 22:45:38

Re: multiple malicious AUR updates

#192 2026-06-20 22:49:07

Re: multiple malicious AUR updates

#193 2026-06-20 22:51:48

Re: multiple malicious AUR updates

#194 2026-06-20 22:58:52

Re: multiple malicious AUR updates

#195 2026-06-20 23:05:11

Re: multiple malicious AUR updates

#196 2026-06-21 07:33:29

Re: multiple malicious AUR updates

#197 2026-06-21 12:22:31

Re: multiple malicious AUR updates

Board footer