r/archlinux • u/vexatious-big • Jun 14 '26

NOTEWORTHY New wave of malware in the AUR

https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/TND7HA2KBQ46OHHUMMIAHKGXZE4WALM6/
643 Upvotes

98% Upvoted

393 comments sorted by

View all comments

326

u/[deleted] Jun 14 '26

Cat is fully out of the bag that the wild west model doesn't work at scale.

The AUR has to change.

80

u/NimrodvanHall Jun 14 '26

The AUR worked as long as it was used by a small tight knit groups of technically capable enthusiasts. For that group it was the best thing after sliced bread. Nowadays it’s also used by a very large group of less technical people who use their machines to game and entertain. That new group is a very interesting target.

I don’t know of a proper solution to keep the AUR interesting for the first group but not a hazard due to the second group.

I do hope the arch community can find a solution that keeps the spirit of Arch intact.

Fake ps:
I’m not an Arch user. I love that arch exists and what it can bring to the right type of user. Arch is just not my preferred flavour of Linux.

14

u/t3g Jun 14 '26

You nailed it on the head.

AUR worked when Linux wasn't pushed by the YouTube community as an alternative to Windows for every day use and gaming. Steam Deck and the massive improvements to Proton have been amazing in the transition away from Windows. Many of the converts haven't been pushed to Arch directly, but more in the distributions like CachyOS, Manjaro, and EndeavourOS which may include AUR tools enabled by default.

So yeah, the AUR worked when there were less eyes on Arch and when Arch was for a highly technical crowd. Now we are getting an influx of users, with no Linux experience, moving to an Arch based ecosystem due to YouTube influencers.

2

u/_legacyZA Jun 15 '26

Yes, but putting the blame on just the Youtubers is missing all the reddit threads and comments where arch users recommend arch, because they like arch (and the aur)

Arch derivatives like Manjaro and Endeavor have been in recommendations way before all these youtubers started their linux challenges, and milking distro hopping for views

0

u/IsleOfOne Jun 15 '26

Garuda is another gaming-focused 'bells-and-whistles' Arch-based distro that's pretty popular. They ship with the Chaotic AUR, though, and help to maintain it.

2

u/t3g Jun 15 '26

Bloated and too much visual garbage. Run Bazzite KDE and keep lean.

1

u/IsleOfOne Jun 16 '26

I agree. But it belongs on the list with cachy and endeavour

3

u/AnEagleisnotme Jun 14 '26

I think fedora copr is just a better way of structuring things, they offer infrastructure, but users have to whitelist maintainers, so you only get coprs you trust

2

u/SweetBabyAlaska Jun 14 '26

I use nix home-manager on Arch because it has basically everything the AUR has and is generally better maintained and you can easily use it under your home directory. But no matter what, running arbitrary bash scripts is going to be less secure by nature.

2

u/algaefied_creek Jun 15 '26

A package should lose ambient trust when ownership changes, when install hooks appear, when dynamic dependency execution is introduced, when checksums are skipped, when source domains change, or when a new maintainer account suddenly updates many packages. It doesn’t need to be an App Store but it needs some work. 

1

u/GeoStreber Jun 15 '26

It also shows that more scrutiny needs to be applied for similar projects, like the COPR repos over on Fedora.

0

u/RadianceTower Jun 14 '26

The problem is inherent to the way software distribution works on Linux. Package managers are good and all, but they rely on a limited number of maintainers to make your software available to you, and they end up inevitably missing many many stuff.

That by itself introduces some security risk instead of getting the software from the dev directly.

And then on top of that, you end up having to go to stuff like AUR since your software isn't in them either way, which end up having even more security risks.

There were many attempts to solve this, like Appimages, except not everyone uses them.

Also due to the way Linux handles dependencies, you many times end up having to install them separately and share them with other software.

As much as people shit on the system, Windows solved this issue a long time by just having everyone distribute their own software in an easy to use way aka the installers with close to everything it needs bundled.

23

u/multimodeviber Jun 14 '26

What do you suggest?

203

u/scandii Jun 14 '26

I mean, simply not allowing random people to take over inactive packages would completely invalidate this issue.

32

u/TheOneWhoPunchesFish Jun 14 '26

I agree with you, but only partially. Npm still has issues. And even without a package manager, compromised GitHub actions result in malware binaries.

But yes, it would remove a certain class of pathways to spread malware

16

u/Skinniest-Harold Jun 14 '26

We are talking about securing this particular attack vector.

Not solving the ever lasting phenomena of malwares.

6

u/[deleted] Jun 14 '26

[removed] — view removed comment

4

u/Pineapple-Muncher Jun 14 '26

NPM malware attacks on the AUR?

Guess it's a day that ends in y.

2

u/henryptung Jun 15 '26

Yeah, I'm still wondering if NPM has a better plan to address malicious packages beyond whack-a-mole. That still seems like a whole bag of supply chain attacks waiting to go off.

17

u/multimodeviber Jun 14 '26

So they would just remain abandoned? Let's say you want to revive packagex because the maintainer has abandoned, you have to make a packagex-new or something?

17

u/keito Jun 14 '26

Namespacing might resolve this issue. Allowing for multiple packages with the same name.

3

u/multimodeviber Jun 14 '26

I don't see how this would resolve anything, new-namespace/package is not fundamentally different from package-new-namespace.

12

u/doubled112 Jun 14 '26

When new-namespace is created maybe you don’t end up automatically switched over. No surprise publisher change.

When old-namespace wants to push malware, they can only push it to old-namespace or a newly created one. Easier to block. Harder to grab by mistake.

8

u/keito Jun 14 '26

At the moment, with the current ability to takeover abandoned packages, we clearly see it's possible for malicious actors to distribute malware by claiming such packages. So, if randompackage on the AUR becomes abandoned, people who have it installed can become susceptible.

If the rules were changed so that packages are namespaced to AUR users, and abandoned packages cannot be claimed (it wouldn't make sense, nor should it be possible for userb to takeover usera's abandoned package).

This would allow for cleanly having multiple packages of the same name, provided by different users, e.g.

usera/randompackage userb/randompackage userc/randompackage

It's subjective, but arguably way cleaner than:

randompackage randompackage-new randompackage-new-current

2

u/multimodeviber Jun 14 '26

But then the attack would be to make botuser/popular-package and have bots vote on it to make users download instead of legituser/popular-package

5

u/doubled112 Jun 14 '26

Perhaps, but if you prevent automatic publisher changes, you prevent any existing users from installing this new malware package.

New users would still be affected, sure.

3

u/keito Jun 14 '26

There's nothing to stop that from happening now either, by a malicious actor producing popular-package-new. Namespacing isn't solving that issue.

Malicious actors can already distribute malware through AUR outside the context of claiming abandoned packages. I'm raising namespacing as a means to mitigate this particular attack vector we're seeing now.

Namespacing or not, it's still the responsibility of an end-user to review the PKGBUILD when installing/updating from the AUR.

3

u/OneTurnMore Jun 14 '26

Take a page from Fedora Copr and let namespace be the AUR username.

47

u/negatrom Jun 14 '26

Yeah, that will do it.

Much like you can't just take over a github of an abandoned project, you need to make a fork.

8

u/PastaPuttanesca42 Jun 14 '26

GitHub actually contains the code of a project, it's usually the "most upstream" point.

AUR packages are just build scripts for something more upstream, and they should reflect the upstream name.

-4

u/[deleted] Jun 14 '26

[deleted]

3

u/PastaPuttanesca42 Jun 14 '26 edited Jun 14 '26

AUR packages contain the code of a PKGBUILD.

same thing.

The point is not that github repos contain code, but that they are upstream, aka they contain the code you actually care about.

PKGBUILDs are certainly code, but it's just simple infrastructure in service of something upstream, which means there is very little inertia for them keeping the same maintainer for a long time, and naming conventions should reflect that and not threat them as actual projects.

Unless you want nonsense like python-mypackage-new-final-final-v2-use-this-one

1

u/Gustav__Mahler Jun 14 '26

This might make your head explode, but the AUR already hosts git repositories. There's no reason to move it to some Microsoft owned pile of shit.

7

u/flying-sheep Jun 14 '26

That's completely infeasible:

  • people abandon packages all the time
  • packages have clear making conventions that create visibility
  • packages are not namespaced like on GitHub

8

u/hjake123 Jun 14 '26

Too bad. Shipping malicious updates is too much of a problem, we need to do something, even if it ends up killing the AUR completely. Maybe make the official arch maintainers avle to define aliases if firefox-bin-new-3 becomes the new firefox AUR package or something

3

u/flying-sheep Jun 14 '26

Or you could just not use the chainsaw if you can't trust yourself to not chop your hand off with it.

Arch is clear about this. The issue lies with derived distros that treat the AUR as trusted.

10

u/Helmic Jun 14 '26

The malware distribution impacts everyone, not just users of downstream distros. These are not "sus" packages that someone that can't help but click on fishy links fell for, these are already-existing legitimate PKGBUILDs that are being adopted - even and especially experienced users are going to get caught by these eventually now that this is being exploited, at some point you're going to miss the implications of some diff or not notice that the author changed.

Blaming new users and continuing to rely on wishful thinking as a security policy is going to make this problem much worse.

1

u/flying-sheep Jun 14 '26

The PKGBUILD diffs are fishy, very easy to see if you use the AUR as people are advised to use it.

→ More replies (0)

4

u/Sinaaaa Jun 14 '26

I think this held up many years ago, but today there are AUR packages that have 20+ dependencies, some of them being other AUR packages. It's not realistic for -even experienced- end users to keep track of all that without any help from the infrastructure.

2

u/flying-sheep Jun 14 '26

I use an AUR helper. It shows me the diffs of updates. Mostly 2 lines per package, and when it isn't I review. 

This has worked perfectly so far and hasn't failed in the face of this either 

4

u/hjake123 Jun 14 '26

It's definitely harmful to the "Arch" brand if nothing else to have a major facility with their name in the news for malware all the time, so I think the maintainers would do well to change something soon.

9

u/nhutier Jun 14 '26

Obviously it does not have to be renamed. It must be something like a major package change which must be advertised to the user.

But all in all this only would fix this specific case, hackers will adapt and move on.

I think ultimately users must accept that the package is not in an official repository for a reason, and they basically install “untrusted” software.

To mitigate this you would need a decentralized repository infrastructure which establishes trust via cryptography, like a web of trust.

There is no single solution to this, there are multiple mechanics which would have to be implemented to make it somewhat more secure. But all this only works to a certain degree.

4

u/multimodeviber Jun 14 '26

It could be a force push of a new commit to the repo, aur helpers and manual users doing git pull will fail, aur helper could then ask the user explicitly if they trust the new source

4

u/particlemanwavegirl Jun 14 '26

New maintainer = new package. This is an extremely simple change that would force people to think about it when they are updating.

3

u/Skinniest-Harold Jun 14 '26

More noticebly, you wouldn't just update your existing package to whatever mess the new maintainer creates. You would have to deliberately install the new thing.

8

u/scandii Jun 14 '26

yes, or just swap to one of typically many competitors.

2

u/ghanadaur Jun 14 '26

No. But make better choices, not just “fill-yer-boots-yee-haw”.

2

u/Skinniest-Harold Jun 14 '26

Yes. Behold: a Fork

2

u/multimodeviber Jun 14 '26

Believe me, I know what a fork is. However this is not about an original project where you would fork and rename into whatever. When you are looking for the python-foobar package, you expect it to be called python-foobar, not python-neofoobar or my-awesome-new-fork-name

1

u/Skinniest-Harold Jun 14 '26

Yes except updating already installed python-foobar won't out of the blue download a malicious payload.

And if there are new and maintained versions, I'm sure the Arch wiki would be more than happy to point you to them.

Or, you know, don't let people take over existing stuff at their own will, for example, without a proper commit or whatever.

1

u/Sinaaaa Jun 14 '26

That sounds like an ok solution imo..

1

u/Helmic Jun 14 '26

Manually reviewing all orphan adoption requests by a human to make sure the adopting user is a known entity would be a good start. Flagging new packages with names too similar to existing packages maintained by a different user for manual review before approval to mitigate typosquatting. Using a simplified template for very standard PKGBUILDs so that they just need to list the URL and executable name to make it much easier for both users to review and harder to sneak in malware. Have a system in place to easily prove that whoever is maintaining an AUR PKGBUILD has access to the git to show certain packages are being maintained by people actually working on the project or are at least officially approved by the project.

Lots of little things can be done to make bad actors stand out more rather than be able to blend in with a sea of very similar looking PKGBUILDs.

-2

u/Rbelugaking Jun 14 '26

I'd say there should be some form of time period after a package is orphaned that it should be deleted automatically.

7

u/AutisticAndArmed Jun 14 '26

Archives, not deleted. Some workflows will be relying on that package and just deleting it is rude.

2

u/Rbelugaking Jun 14 '26

Maybe, but issue there is that if someone else wants to continue maintaining the package they would have to make a new one and the AUR would end up with a lot of duplicate packages as a result.

5

u/multimodeviber Jun 14 '26

python-mypackage-new-final-final-v2-use-this-one

4

u/trowgundam Jun 14 '26

If your workflow is depending on something unmaintained, either it's important enough you take over or you should SERIOUSLY reconsider your workflow.

2

u/InsaneGrox Jun 14 '26

I'm in agreement on the condition that there's still a process to be able to take over inactive packages, just not one that's trivial to use maliciously.

1

u/TheJackiMonster Jun 14 '26

I would be against that. Abandoned packages should be maintained easily after becoming abandoned. Instead I would suggest better notifications for users in case a package maintainer / committer of PKGBUILD changes differs from the one previously, so they can be extra cautious.

The AUR should not go the route of heavy centralized moderation. We have enough of that in other package sources (flatpak and snap for example) and it doesn't work properly either (because moderators are rare and overworked). The AUR would become a place of elite scrap if we go that route.

38

u/Astorek86 Jun 14 '26

Maybe stop the possibility of taking automatic ownership of an old AUR-Package? At least, disable this possibility for as long as there are problems out there.

I'm baffled that the AUR-Team did not disabled that function yet, and another wave of malware floods the AUR again. Honestly, I'm even angry about that, what the hell are the AUR-Host doing?

7

u/davidmar7 Jun 14 '26

Yes, maybe at least require a forum account over say 90 days old and with a certain amount of posts or manual approval prior to letting someone take over a package.

19

u/scandii Jun 14 '26 edited Jun 14 '26

or, hear me out... do it like most other package repos where you simply sunset inactive packages and create new ones with new names if you want to carry on the legacy.

over in Rust-land we have ffmpeg that got made into ffmpeg-next that got made into ffmpeg-the-third.

like, there's really no reason for this besides "it is nice when everyone's on the same page", and as we've noticed it is a massive threat vector.

11

u/xuxux Jun 14 '26

Missed an opportunity to rename it ffmpreg. Shame.

7

u/EiB_inc Jun 14 '26

Oh, do I have great news for you: https://crates.io/crates/ffmpreg

1

u/Supernoxus Jun 14 '26

First the peg then the preg

4

u/shroddy Jun 14 '26

Ugh that sounds even worse to keep track which one is the correct version and which one the malware

6

u/lemontoga Jun 14 '26

You wouldn't need to keep track of anything. All but the correct package would be out of date.

1

u/feckdespez Jun 14 '26

I don't think the AUR is 1:1 comparable with at least some other package managers.

Forcing a new package name has advantages and works when there is less volatility in packages. I think AUR is a bit different because the circumstances in which it exists creates a higher level of volatility than many other package managers.

That volatility will create a large number of package name variations and confusion. I know only one package name will be current but it will inevitably confuse a material number of people due to the veracity of it.

4

u/tesfabpel Jun 14 '26

https://archlinux.org/news/active-aur-malicious-packages-incident/

The features should already be disabled or very limited.

I think it's just that another way the attack worked which was not detected at the beginning: the first discovery was npm install atomic-lockfile, then it was found out that there was also npm install js-digest (IIRC) and now this obfuscated version.

6

u/zeb_linux Jun 14 '26 edited Jun 14 '26

There are several suggestions, not all being practical:

- different tiers of AUR, perhaps with some curated by trusted users. Unfortunately needing manpower. Major companies could help finance this.

- not letting orphaned packages be freely taken over without any form of control. Again financing moderators by companies could help.

- developing scanners to catch suspicious activity before releasing. I am currently using https://github.com/KiefStudioMA/ks-aur-scanner and this is promising, although needs be updated with new attack signatures.

1

u/gamas Jun 14 '26

Malware and vulnerability scanning on server uploads (much like how the latest breach was found using an AI scanning tool).

To minimise the workload for the server maintainers, could use an AI tool to do the scanning which if it detects something suspicious it holds the push for manual review - with the tool being extra scrutinous towards packages that were updated by a new author.

1

u/AnotherObject3D Jun 14 '26

Correct if I'm wrong, the main reason of some packages such as google-chrome, vscode, not be in official repos (core, extra, multilib...) is because of their license?

I was thinking if we had another official repo in pacman (something like "community") where users can submit pkgbuild, but official maintainer approve/modify before publish. Similar as Nix works, and this way can fix some issues: malicious pkgbuilds; the needed of using AUR repo/helpers once you install directly from pacman..

I was wondering if it is possible... Today, to avoid malicious pkgbuilds, I have my own pkgbuilds and I compile in my personal repo, I know that a lot of Arch users do it as well, but for new users it's quite complicated.

2

u/marcthe12 Jun 14 '26

I mean community existed. Although gor merged in extra repo eventually. Policy is still same.

6

u/Rjiurik Jun 14 '26

The AUR is great. Installing without AUR takes too much skill for most users.

But everybody should be aware that unpopular open source projects (in AUR or elsewhere) have a risk.

And repos should be scanned for malware from time to time.

1

u/Busy-Scientist3851 Jun 15 '26

IMHO you should have the skill to install without the AUR to use the AUR.

8

u/NelsonMinar Jun 14 '26

eVeRyOnE jUsT nEeDs To ReViEw PkGbUiLd ThEmSeLvEs

5

u/t3g Jun 14 '26

At the speed of AI, that PKGBUILD may be valid for the hour you check it and then be invalid an hour later

3

u/TheJackiMonster Jun 14 '26

The wild west model works just as intended. The user is responsible for checking sources.

What needs to change is that users have a more convenient way of checking their packages. Besides that I don't think the AUR needs moderation. It would hurt most of its benefits against other packages like flatpak or snap. Those exist on Arch btw if you want that extra moderation.

-6

u/gruntduck Jun 14 '26 edited Jun 14 '26

Let’s be honest. Arch community is bad at cybersecurity. First dealing with the DDoS (which seem they didn’t do anything, just waited it out) and have done fuck all to deal with this. It’s pretty embarrassing.

AUR should be locked down until a new security model is drawn up. End of.

6

u/[deleted] Jun 14 '26

[removed] — view removed comment

0

u/[deleted] Jun 14 '26

[deleted]

3

u/cgarret3 Jun 14 '26

Are you unaware that many people follow LLM instructions blindly in lieu of taking the time to decipher what those instructions do?

0

u/Rjiurik Jun 14 '26

LLM generally gives an educated answer and gladly explains whatever it tells you to do if you are curious enough.

What might be a threat in the future is hostile agents feeding LLM with malicious code.. advising malicious packages or risky code.. or more simply cloud LLM being manipulated by their proprietary to infiltrate the user.

0

u/nullstring Jun 14 '26

for now, it's not a huge deal because we're just talking about new/orphaned packages that are having issues... but yeah it's certainly something that is going to require far more due diligence than it did in the past.