Comments below is from the perspective of an arch Linux user, not maintainer or authors of some software.
When installing softwares on arch Linux, first searching for official packages provided by Arch Linux maintainers, then official installation methods approved by authors of the software, or AURs which do the installation in the exact way as the authors of the software describe.
A search on the default installation method of Firefox and librewolf package on arch Linux is listed below.
If AUR is required to install a package, note that AURs are not trusted by default because not all AURs are not maintained by trusted users. Always check the source file and the installation method documented in PKGBUILD. Don't do the installation until EVERY line in the PKGBUILD is reasonable.
This shouldn't reasonably be considered secure because it isn't altogether hard to obscure the nature of the attack until someone notices they are compromised.
Could there be programmatic ways to help users characterize the safety of the AUR packages they install? Perhaps a program that prints all URLs in the PKGBUILD and offers the option for the user to open them in the browser? Or which automatically shows a diff if a PKGBUILD is updated? Highlighting changes would make it easier for the user to determine if he should spend time exploring those changes for malware.
One could go even further and list all new commits, making it super easy for the user to check them. Maybe even integrate an LLM to help? Maybe commits from non long-time contributors could be flagged?
There has to be a way to help users programmatically review updates to their AUR packages. Even if most of them won't spend the time.
PKGBUILDs are just bash scripts following a certain function and variable naming convention. Even if you could somehow parse it safely and extract the URLs of the 'source' array, any attacker can just simply put an obfuscated version of the malware URL into the build() function and download it there.
AUR clients already show you the diff if you update a package, but note that this were completely new packages anyway, uploaded 2 days ago, so that doesn't really apply here.
LLMs are useless for reviewing if something is malicious, their false-positive rates would be way to high. And even ignoring that you'd have to hide the LLMs code from the attacker or he can just check if his package is detected as malicious and modify it until it isn't. Not something open source projects are keen on doing.
As one commentor pointed out, in Arch it's the user's responsibility to review any AUR packages BEFORE installing them (and I say this as an Arch user and AUR package maintainer).
This particular issue is with a binary (i.e. pre-built) package, normally in Arch it's expected from an AUR package that you will build it yourself and most if not all packagers prompt you to review and or edit the PKGBUILD before it does anything.
Basically you could spot something suspicious in a source package, not so much in a binary package.
Nearly all distros have this problem when it comes to packaging and distributing 3rd party software.
Even if you're using an immutable distro, your KDE Plasma session can get hijacked if you simply use the built in wizard to install 3rd party desktop widgets, which is a right-click + single-click away on any Plasma destkop.
Any clue what these packages were 'supposed' to do or why somebody might have installed them? Their PKGBUILD descriptions are copies of the respective browsers', not explaining the -patched part.
Looks like someone archived the page of firefox-patch-bin[1] and the only thing that stands out about the package itself is that it's supposedly the "Extended Support Release." Besides that it looks like it's depended on by 183 other packages/metapackages. While that seems more interesting, there isn't an archive of all of those packages.
I wondered about the same thing. Not an answer, but my guess would be that it's just a new package and they hoped someone picked it up by accident?
In that case, it was patched with malware :)
I wonder how popular these packages were. Librewolf and Firefox sure are popular, so this sounds scary, but for example searching for "firefox-patch-bin aur" yields no results, aside from sites talking about how it contained malware.
My impression is that the malice was spotted timely, and not many people were affected. Which is a pretty good thing!
it should be noted that these are different from the popular librewolf-bin (513 votes) and zen-browser-bin (176). with this in mind it's cool that these got identified only 2 days after being uploaded. I wonder if the reporter actually intended to install it or just reads the PKGBUILDS of new packages to be a good samaritan...
Why would it be? AUR is user generated content by definition, you're expected to read and understand every package before using it, which is repeated in documentation ad nauseam. They're very, very explicit about this and that you're on your own when using AUR.
All decent AUR helpers (which arch developers advise against using anyway) force you to read through the packaging script and confirm that you understand it and are fine with what's about to be executed.
It's no more of an issue than someone posting a malware script into e.g. the wiki. Much less obscure than malware in npm or anything like that.
There's always been this security theater of people recommending arch because they "don't trust the companies" or Canonical or what have you but frankly I'm surprised this hasn't happened sooner. Well or maybe it has and we don't know.
Running random binaries on your computer uploaded by some anonymous dude has to be the equivalent of buying heart medicine on craigslist. And because Arch is so barebones to begin with the AUR is very popular, you see a lot of arch users using it.
Not a single enterprise distro even reacts within that timeframe. OVAL advisories are weeks, sometimes months later.
As long as you don't have a virtualization approach similar to QubesOS, any linux distro will not fix this problem. Because that's not how separation of concerns works in the POSIX system. You need to have separate users for each and every program to isolate them, and that is practically unfeasible.
I agree, it's much better in Ubuntu land where you simply won't have the software at all, will shrug your shoulders and go on with your life.
AUR helpers make reviewing changes to AUR packages a trivial matter that takes about 2 minutes of my life per month. In exchange I get easy access to software that isn't packaged for Ubuntu and probably never will be, because building debs and going through the process of upstreaming them is roughly comparable to getting a PhD (if anyone is even interested in your debs, which they probably won't be).
How exactly is Arch barebones? It basically ships with everything I need, more than most distros (Zed and Discord are good examples). I don't even need to use the AUR.
i installed a lot of cra* from aur in the past, wouldn't be surprised if i got a malware somewhere. Strange thing, I don't think open snitch would even help in such situation..
and official repo does not have enough packages to run arch :\
I don't want to go back to ubuntu
I haven't taken a look at the malware, but it seems to download files from the Internet so it should have warned you to allow/deny the outbound connections.
It'd be nice to test it with a sample of aur package/malware.
> We strongly encourage users that may have installed one of these
packages […] to take the necessary
measures in order to ensure they were not compromised.
How are they supposed to do that when you give them no information as to what the malware does?
It says what the malware does, it's a remote access toolkit... It gives control of your machine to the malware operator.
The malware operator could have done anything with that access... There's no way for the maintainers to know what was done on any given infected machine.
It's a remote access trojan. There is no acceptable way to be sure of removal short of full reinstalling every OS installed and reinstalling or rebuilding stuff in the Home dir from known good sources.
First of all, this is incorrect, the checking would have to happen _before_ even building the package since malware is already being executed at that point.
But more importantly this is a terrible idea in regards to privacy/infosec. I do not want packages I build and install myself to be uploaded to a 3rd party website.
And for what benefit? 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR.
Is this accurate? My understanding is that the AUR does not host binary packages. It hosts pkgbuild files, which contain config and scripts that a user has to build on their own machine in order to install. The malicious code here is fetched as part of those scripts.
> Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package.
AFAIK, VirusTotal only flags known malware/viruses, any new/"looks-to-be-new" stuff wouldn't be flagged until they've picked it up, and once someone would have picked it up, it should be removed from the AUR anyways. So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless.
Just create a pacman hook before install that uploads the package there and aborts installation if necessary. Probably skipping repo packages is a good idea otherwise you're gonna spam the API each update.
RandyOrion|7 months ago
When installing softwares on arch Linux, first searching for official packages provided by Arch Linux maintainers, then official installation methods approved by authors of the software, or AURs which do the installation in the exact way as the authors of the software describe.
A search on the default installation method of Firefox and librewolf package on arch Linux is listed below.
If AUR is required to install a package, note that AURs are not trusted by default because not all AURs are not maintained by trusted users. Always check the source file and the installation method documented in PKGBUILD. Don't do the installation until EVERY line in the PKGBUILD is reasonable.
https://wiki.archlinux.org/title/Firefox
https://librewolf.net/installation/arch/
michaelmrose|7 months ago
heavyset_go|7 months ago
techjamie|7 months ago
lorenzohess|7 months ago
One could go even further and list all new commits, making it super easy for the user to check them. Maybe even integrate an LLM to help? Maybe commits from non long-time contributors could be flagged?
There has to be a way to help users programmatically review updates to their AUR packages. Even if most of them won't spend the time.
Tharre|7 months ago
AUR clients already show you the diff if you update a package, but note that this were completely new packages anyway, uploaded 2 days ago, so that doesn't really apply here.
LLMs are useless for reviewing if something is malicious, their false-positive rates would be way to high. And even ignoring that you'd have to hide the LLMs code from the attacker or he can just check if his package is detected as malicious and modify it until it isn't. Not something open source projects are keen on doing.
WD-42|7 months ago
IceDragon200|7 months ago
This particular issue is with a binary (i.e. pre-built) package, normally in Arch it's expected from an AUR package that you will build it yourself and most if not all packagers prompt you to review and or edit the PKGBUILD before it does anything.
Basically you could spot something suspicious in a source package, not so much in a binary package.
porridgeraisin|7 months ago
WD-42|7 months ago
johnisgood|7 months ago
heavyset_go|7 months ago
Even if you're using an immutable distro, your KDE Plasma session can get hijacked if you simply use the built in wizard to install 3rd party desktop widgets, which is a right-click + single-click away on any Plasma destkop.
yuvadam|7 months ago
ASalazarMX|7 months ago
mzajc|7 months ago
Vortigaunt|7 months ago
[1]https://web.archive.org/web/20250718140411/https://aur.archl...
Jorchime|7 months ago
npteljes|7 months ago
My impression is that the malice was spotted timely, and not many people were affected. Which is a pretty good thing!
christophilus|7 months ago
This makes me nervous. I guess it’s time to do some audits.
lilly-lizard|7 months ago
Shellban|7 months ago
akerl_|7 months ago
homebrewer|7 months ago
All decent AUR helpers (which arch developers advise against using anyway) force you to read through the packaging script and confirm that you understand it and are fine with what's about to be executed.
It's no more of an issue than someone posting a malware script into e.g. the wiki. Much less obscure than malware in npm or anything like that.
Barrin92|7 months ago
Running random binaries on your computer uploaded by some anonymous dude has to be the equivalent of buying heart medicine on craigslist. And because Arch is so barebones to begin with the AUR is very popular, you see a lot of arch users using it.
h4ck_th3_pl4n3t|7 months ago
Not a single enterprise distro even reacts within that timeframe. OVAL advisories are weeks, sometimes months later.
As long as you don't have a virtualization approach similar to QubesOS, any linux distro will not fix this problem. Because that's not how separation of concerns works in the POSIX system. You need to have separate users for each and every program to isolate them, and that is practically unfeasible.
homebrewer|7 months ago
AUR helpers make reviewing changes to AUR packages a trivial matter that takes about 2 minutes of my life per month. In exchange I get easy access to software that isn't packaged for Ubuntu and probably never will be, because building debs and going through the process of upstreaming them is roughly comparable to getting a PhD (if anyone is even interested in your debs, which they probably won't be).
WD-42|7 months ago
defraudbah|7 months ago
and official repo does not have enough packages to run arch :\ I don't want to go back to ubuntu
gus_|7 months ago
It'd be nice to test it with a sample of aur package/malware.
jabjq|7 months ago
How are they supposed to do that when you give them no information as to what the malware does?
rwmj|7 months ago
More interesting questions are:
- Who was the uploader? A packager? For how long?
- Do they maintain other packages?
- What steps can be taken to ensure that a similar problem doesn't happen in future?
gpm|7 months ago
The malware operator could have done anything with that access... There's no way for the maintainers to know what was done on any given infected machine.
Ancapistani|7 months ago
michaelmrose|7 months ago
npteljes|7 months ago
jchoksi|7 months ago
They have to be installed via "pacman -U package_file"
Arch developers can code "pacman -U" such that it performs a VirusTotal scan before installation for each package.
VirusTotal's API is free.
- https://docs.virustotal.com/docs/api-scripts-and-client-libr... - https://docs.virustotal.com/docs/please-give-me-an-api-key - https://docs.virustotal.com/docs/consumption-quotas-handled
Since it is end users who are doing the upload and virus scan check, there won't be a consumption quota issue with VirusToal.
Lastly, "pacman -U" should flag failed VirusTotal scans to Arch Security.
Arch's pacman and Flathub's flatpak package managers should be the last line of defence when installing untrusted packages by end users.
Tharre|7 months ago
But more importantly this is a terrible idea in regards to privacy/infosec. I do not want packages I build and install myself to be uploaded to a 3rd party website.
And for what benefit? 99% of new malware won't be detected anyway, and once it is known it is way more effective to just remove the offending package from the AUR.
akerl_|7 months ago
diggan|7 months ago
AFAIK, VirusTotal only flags known malware/viruses, any new/"looks-to-be-new" stuff wouldn't be flagged until they've picked it up, and once someone would have picked it up, it should be removed from the AUR anyways. So you'd have at least one user (most likely more) getting infected first, and once detected more users wouldn't be able to install it regardless.
OsrsNeedsf2P|7 months ago
icar|7 months ago