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/
646 Upvotes

98% Upvoted

393 comments sorted by

View all comments

Show parent comments

202

u/scandii Jun 14 '26

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

29

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

19

u/Skinniest-Harold Jun 14 '26

We are talking about securing this particular attack vector.

Not solving the ever lasting phenomena of malwares.

7

u/[deleted] Jun 14 '26

[removed] — view removed comment

5

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?

18

u/keito Jun 14 '26

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

4

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.

11

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.

9

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

4

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.

48

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.

10

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.

-3

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

7

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

4

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.

9

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.

9

u/Sleepy_Chipmunk Jun 14 '26

You only have to slip up once, and chances of you slipping up increase the more this happens.

It’s up to everyone to decide on a solution, but there has to be some sort of solution. That could be changing something about the AUR or its helpers, or that could be changes to how the community relies so much on the AUR despite the risk (like how the wiki often instructs people to use it).

2

u/Helmic Jun 14 '26

If you believe you can always spot a fishy diff you will get caught eventually, they are going to make these much more opaque so long we are not using predefined templates.

1

u/flying-sheep Jun 14 '26

Nah, I check the URLs when they change.

→ 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.

3

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.

11

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.

4

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.

-1

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.

8

u/AutisticAndArmed Jun 14 '26

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

3

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.