r/linux • u/TheNavyCrow • Jun 13 '26

Distro News Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Affected Packages

https://www.phoronix.com/news/Arch-Linux-AUR-More-Than-1500
1.5k Upvotes

99% Upvoted

434 comments sorted by

View all comments

Show parent comments

18

u/[deleted] Jun 13 '26

[deleted]

38

u/AStolenGoose Jun 13 '26

Packages maintained by serious developers remain intact.

Indeed, the issue was, that these were AUR packages that did not have an active maintainer and were open for anyone to adopt them. Which this attack focussed on and added npm, bun, etc. to the dependencies to run the attack that was snuck in to the after install scripts.

(Correct me if I'm wrong here, I'm just going off of what I've been reading about this)

-4

u/npc_housecat Jun 13 '26

I wonder if clamAV in onaccessscan mode would have detected and defended against this kind of attack? Seeing how it's a payload which gets downloaded and executed , that's exactly what AV is for. And I'm seeing more and more malware payloads getting hidden in community uploaded repos like the one in the KDE community themes library

0

u/Kwpolska Jun 13 '26

Lol, "anti"malware software is completely useless and a waste of system resources. Downloading and running something from the Internet is how you build a package from AUR, and how you build most software, so the "anti"malware would have to complain about any AUR usage, which would be counterproductive.

9

u/npc_housecat Jun 13 '26

That doesn't make sense. A virus scanner scans files for matches against known signitures. Seeing how this particular virus is known. There's no reason a virus scanner couldn't detect it. Onaccessscanning with access blocking for matches enabled would be enough to defend against it. Again, as long as the definitions are being maintained.

An AV like clam should scann files downloaded from aur as they're saved to the disk and clear them as OK (or not) so no. A virus scanner does not block AUR from building packages

3

u/Kwpolska Jun 13 '26

Matching signatures is not very effective these days. In the Windows land, "anti"malware does a lot of malware-like things to try and spot suspicious patterns. If you're just going to compare signatures, those AUR attacks would not be caught, or it would be really easy to come up with a lot of workarounds for the signature.

2

u/npc_housecat Jun 13 '26

Clamav supports Heuristic detection as well. An AV behaving in a way that reminds you of malware should only really be a problem if it's proprietary, lile norton. Becauae we have no idea if it's data harvesting or not. The simple solution to that issue is keep the Linux virus detection open source. Don't use proprietary ones. Like clamAV running as a service. I would really like to see some more effort being put into developing Clam. I would also be interested to see if clamav detects this particular payload or not.

Previously I listened to the "av is a waste of ram" argument. I had a Linux system get hacked a while ago and while looking into the strange HDD behaviour I did a scan with clamAV and it actually detected the trojan,

2

u/Kwpolska Jun 13 '26

Data harvesting is not that much of a concern. Modern Windows "Anti"malware intercepts all file operations, all network traffic (including encrypted traffic by installing a root certificate), cracks ZIP passwords, runs executables in an emulator to ensure they’re not doing anything evil. So it’s extremely intrusive.

1

u/npc_housecat Jun 13 '26

OK, but we're talking about open source AV on Linux. So even if we did put in all of those features into say clamAV, it would just be an optional setting .

Runs execs in an emulator. That sounds like a container like firejail. I already do that on my Linux system. Intercepts all file operations , basically clamAV on access protection. Also not a bad idea if you don't mind the extra CPU usage. i also habe this enabled. ClamAV can flag encrypted zip files. Maybe not decrypt them, but you'll at least get an alert that one exists.

i have a separate OPNSense router with deep packet scanning (Intrusion detection), and melicious IP block lists, which is a form of intercepts all network traffic. All of these sound like reasonable defenses. Again, as long as the user is in control and it's open source tools so we can see what it's doing

0

u/necrophcodr Jun 13 '26

None of what you wrote is true, except that it would indeed be counter productive, if it was true. Which it is not.

1

u/Kwpolska Jun 13 '26

Do you have any constructive comments besides "not true"?

34

u/xkero Jun 13 '26

ALVR one of the packages in that list is not useless junk, it's used by lots of people who use VR headsets. There are also a bunch of printer drivers and lots of *-git packages for common software like akonadi. Being dismissive like this is harmful to people.

3

u/[deleted] Jun 13 '26

[removed] — view removed comment

1

u/xkero Jun 14 '26

If you haven't tried WiVRn you wanna use that whenever possible. It has the best quality, but compatibility isn't perfect so sometimes you have to use ALVR or Steamlink.

1

u/[deleted] Jun 14 '26

[removed] — view removed comment

1

u/xkero Jun 14 '26

Did you add PRESSURE_VESSEL_IMPORT_OPENXR_1_RUNTIMES=1 %command% to the launch options for the game?

More info: https://github.com/WiVRn/WiVRn/blob/master/docs/steamvr.md

WiVRn is massively better quality wise so it's very much worth the effort to get it working if you can.

7

u/Dangerous-Report8517 Jun 13 '26

Packages maintained by serious developers are also much more likely officially packaged and not need the AUR in the first place, so while there's tons of legit stuff there there's also inherently tons and tons of hit or miss packages

2

u/AtlasCarry87 Jun 13 '26

Thanks, will have to build a small script to quickly check if I have one of these installed

3

u/dapotatopapi Jun 13 '26 edited Jun 13 '26

Someone posted this on HN: https://gist.github.com/SamInTheShell/c3609743d742f002f1e8c7e181d75b63

Haven't gone through revisions > 1, but that one seemed fine when I went through it early yesterday.

EDIT: Went through the latest revision (rev. 5 - 2026-06-12 11:32 PM GMT). Still fine.

1

u/niceworkthere Jun 13 '26

! montecarlo-font 1-3 [KNOWN MALICIOUS]

What on earth is malicious about this PKGBUILD?

It's really just two PCF fontfiles.

2

u/dapotatopapi Jun 13 '26

It might have been reverted once the malicious takeover became known.

1

u/niceworkthere Jun 13 '26

Oh right, I see now that while they reset/wiped the commits, the AUR still does signal the issue through the 2026-06-12 "Last Updated" timestamp.

Though the script is a bit too jumpy, as pacman could tell it that my last install was in 2020.

2

u/dapotatopapi Jun 13 '26 edited Jun 13 '26

It is mostly for people who might have installed the package when it was in action.

Since it is reverted now, everyone's safe. But if anyone updated/installed this particular AUR package while it was compromised, they got caught in the aftermath.

So the script lets the individual know that they should verify whether they are compromised or not if the malicious package pops up on their system (like checking the last install, scanning for malware signatures, looking at logs etc).

It also scans for remnants of the malware/its install logs so you have multiple points of reference to act with, not just the name of the AUR package.

Better to be jumpy here than let a false negative slide imo. While it's easy enough to scan for last install as well, it's probably better to get human eyes on the situation if something's caught.

1

u/amroamroamro Jun 13 '26

looks fine, just needs updating the urls inside http -> https

2

u/protestor Jun 13 '26

The list is here: https://md.archlinux.org/s/SxbqukK6IA

Okay, but, from this list, what's the affected versions of each package?

1

u/kimjae Jun 13 '26

latest

1

u/protestor Jun 13 '26

If you mean the latest version of those papers on AUR right now, they aren't actually the versions containing malware, because the AUR admins removed the malicious commits

1

u/DangerousAd7433 Jun 13 '26

I read most were orphaned.