this post was submitted on 18 Jul 2025

113 points (100.0% liked)

Arch Linux

8952 readers

15 users here now

The beloved lightweight distro

founded 5 years ago

MODERATORS

k_o_t@lemmy.ml

113

Compromised Arch User Repository (AUR) Packages, installing RAT malware (lists.archlinux.org)

submitted 1 week ago* (last edited 1 week ago) by Fubarberry@sopuli.xyz to c/archlinux@lemmy.ml

23 comments fedilink hide all child comments

On the 16th of July, at around 8pm UTC+2, a malicious AUR package was uploaded to the AUR. Two other malicious packages were uploaded by the same user a few hours later. These packages were installing a script coming from the same GitHub repository that was identified as a Remote Access Trojan (RAT).

The affected malicious packages are:

librewolf-fix-bin
firefox-patch-bin
zen-browser-patched-bin

The Arch Linux team addressed the issue as soon as they became aware of the situation. As of today, 18th of July, at around 6pm UTC+2, the offending packages have been deleted from the AUR.

We strongly encourage users that may have installed one of these packages to remove them from their system and to take the necessary measures in order to ensure they were not compromised.

According to the gamingonlinux discord, the following packages are also suspected to be compromised:

https://aur.archlinux.org/pkgbase/minecraft-cracked/

https://aur.archlinux.org/pkgbase/ttf-ms-fonts-all/

https://aur.archlinux.org/pkgbase/vesktop-bin-patched/

https://aur.archlinux.org/pkgbase/ttf-all-ms-fonts/

If you have any of these packages installed, immediately delete it and check your system processes for a process called systemd-initd (this is the RAT).

Here is an analysis of the malicious payload: https://www.virustotal.com/gui/file/d9f0df8da6d66aaae024bdca26a228481049595279595e96d5ec615392430d67

all 24 comments

sorted by: hot top controversial new old

[–] slackness@lemmy.ml 36 points 1 week ago (5 children)

As a package maintainer in AUR, I never understood the awe with it. You're literally executing random shell scripts by strangers as root. It's the same thing as curl | sudo bash except its a lot easier to hide malicious things.

Most people claim they read the PKGBUILD (which I don't believe tbh) but I bet they don't read <package>.install scripts which don't have to be explicitly mentioned in the PKGBUILD if it shares the same name as the package.

I could push whatever I want to my package and hundreds of people will pick it up. Since I'm not a script kiddie like this guy, I could hide it much better too.

I guess what I'm saying is, don't execute unvetted bash scripts as root kids. Open source doesn't mean people verify the code. It just means they can.

[–] Eyck_of_denesle@lemmy.zip 3 points 1 week ago (1 children)

Because i don't have a track the updates and manage it's uninstall

[–] patatahooligan@lemmy.world 3 points 1 week ago (1 children)

.install scripts which don’t have to be explicitly mentioned in the PKGBUILD if it shares the same name as the package.

Can you show a reproducible example of this? I couldn't get a .install included in a test package I made without explicitly adding it as install=<package>.install.

Most people claim they read the PKGBUILD (which I don’t believe tbh)

If you don't trust people to read PKGBUILD's I'm curious which form of software installation (outside of official repositories) you find safe.

[–] slackness@lemmy.ml 3 points 1 week ago* (last edited 1 week ago) (1 children)

Can you show a reproducible example of this? I couldn’t get a .install included in a test package I made without explicitly adding it as install=.install.

I might be misremembering that detail or it might've changed since the last time I wrote a fresh PKGBUILD. Sorry I don't have any examples because my project does not use an install script.

If you don’t trust people to read PKGBUILD’s I’m curious which form of software installation (outside of official repositories) you find safe.

My preference goes Arch repos -> official aur packages that I read the manifests of -> verified flatpaks that I read the manifests of -> Nix -> compile myself

[–] Tenderizer78@lemmy.ml 2 points 1 week ago

The way Nix handles things seems so cool. And if you want to prevent a program from doing things it's not supposed to then a protocol that makes sure it has it's own copy of everything it's allowed to use would be necessary (if development isn't gonna be super obtuse).

[–] Hawk@lemmy.dbzer0.com 0 points 1 week ago

Might as well ditch your computer and grab a notebook.

[–] jatone@lemmy.dbzer0.com 0 points 1 week ago (1 children)

the love of the aur is the lack of friction to distribute and install software. these security breaches are meh they're found and resolved. it'd be nice if we sandboxed applications more.

[–] slackness@lemmy.ml 7 points 1 week ago (1 children)

Yeah good luck sandboxing a service running as root at boot. Maybe look at the malware next time before trying to call it meh?

[–] jatone@lemmy.dbzer0.com 2 points 1 week ago* (last edited 1 week ago) (1 children)

You asked why people like the AUR and I informed you. not everything is a crisis. peoples computers get compromised every single day. (and yes it sucks for them)

Now you may want to get into a pissing contest over how easy it is to containerize installations on linux today, I personally have no interest in educating peanut gallery commentators.

the basics are: you essentially can't do anything about the applications themselves but securing the installation process is straight forward these days. our package managers are just not funded so the work is slow as shit.

now go outside and touch some grass for everyone's sake.

[–] slackness@lemmy.ml 3 points 1 week ago (1 children)

Starts with:

it’d be nice if we sandboxed applications more.

Turns into:

you essentially can’t do anything about the applications themselves

Not only contradicting with themselves but are also wrong in both cases. I don't know who tf is upvoting this pile of unintelligable crap.

but securing the installation process is straight forward these days.

No.

[–] jatone@lemmy.dbzer0.com -2 points 1 week ago* (last edited 1 week ago)

lol. child. we cant directly do anything if the program itself is compromised outside of sandboxing it. which we do have wrappers for. in fact we have a ton of them now. but sandboxing at the system level is more complicated than at the user level. because either you need to whitelist every possible system access and have it approved or deal with the occassional security issue as this post is about. one is much easier than the other.

but sandboxing the installation process is fairly easy since thats in your package manager. basically just wrap up a bash implementation in a wasi runtime and restrict it and you're golden, you'll have blocked network and filesystem access. all the problems with the installation scripts can be directly controlled via that mechanism.

we just dont do it because its a lot of work with minimal benefit and no one is paying for it to be done.

just because you dont know what the solution space is doesnt mean others dont.

again go touch some grass. you clearly need to.

[–] ArtixCory@lemmy.ml -1 points 1 week ago (1 children)

You’re literally executing random shell scripts by strangers as root.

You're literally not doing that. Escalated permissions are needed for installing dependencies and installing the resulting package, not for building. Just try running makepkg as root and see what happens.

[–] sudo@programming.dev 2 points 1 week ago (1 children)

Yes you literally do when you install the package. You're thinking of building the package. makepkg -i will prompt for root. pacman -U requires root. Both will execute the install() function of the PKGBUILD as root.

[–] ArtixCory@lemmy.ml 1 points 1 week ago (1 children)

Not every PKGBUILD contains a .install file. So again, it is not inherently the case that you’re "literally executing random shell scripts by strangers as root." slackness has it right that most people probably don't read the install files, but it seems to me that their prevalence in the AUR is overstated here.

[–] slackness@lemmy.ml 1 points 1 week ago (1 children)

Why don't you just google (or ask an llm if thats too challenging) instead of making stuff up?

[–] ArtixCory@lemmy.ml 1 points 1 week ago* (last edited 1 week ago) (1 children)

What am I making up? That most AUR packages don't have a .install file? You couldn't be bothered to say what I got wrong or provide any evidence to back it up so I can only assume. But if you have issue with me speculating about how common .install files are in the AUR, fine. Here are some numbers.

Out of the 2500 packages I analyzed, only 19.08% of them had an install list in their PKGBUILD. One could very easily use the AUR and never, and I quote, "literally [execute] random shell scripts by strangers as root."

I also dug deeper regarding your claim that install files "don't have to be explicitly mentioned in the PKGBUILD if it shares the same name as the package." I can't find any evidence of that. It doesn't have to be listed in the sources, which is probably what you meant.

Clearly these couldn't be the things I'm wrong about, so I await your careful clarification.

edit: Alright it's clear that you're not capable of grown-up discussion. You're blocked.

[–] slackness@lemmy.ml 0 points 1 week ago