" Arch AUR Under Fire Once More as Malware Resurfaces"
“Just ten days after a previous incident, malware with a Remote Access Trojan has once again been discovered in Arch Linux AUR packages.”
" Arch AUR Under Fire Once More as Malware Resurfaces"
“Just ten days after a previous incident, malware with a Remote Access Trojan has once again been discovered in Arch Linux AUR packages.”
If you are just clicking and typing in arbitrary commands from websites, it is just a matter of time before it catches up to you on any OS, not just Linux.
Common sense goes a long way and is your best antivirus!
I guess AUR should have some kind of security system, some kind of scanning tool for all added packages, something like Google Play has.
Neither Arch nor Cachy provides any extra ‘protection’ from these malicious PKGBUILDs.
The AUR is an open, public, repository.
Anyone can add anything.
Thats how it always has been.
So its up to the user to inspect and verify anything they get from there.
If you do that then there should be no problems.
If you do not .. then you are just playing roulette.
Just like how Arch’s philosophy on security in general is that security “is something you configure”. You can lock down your system to the point it has little practical purpose. You can just as easily install and never start/use a firewall. Is that a good idea? Its your system - only you know for sure.
By default there shouldnt be any real need - the packages in the repositories are vetted.
Besides the already mentioned philosophical perspective;
But it should also generally be understood that these configurations are often trade-offs.
If all the applications are ‘sandboxed’ then can they access your peripherals?
Anything from antivirus to firewall to even kernel-level mitigations can have performance impacts.
Are you willing to trade 25% of your computing power for ‘security’ that is not pertinent to your situation?
Etc, etc, etc.
While you can implement most any security stratagem you might like with Cachy, if you want an ultra-secure-out-of-the-box (read: locked-down, SELinux) linux distro you should probably look elsewhere.
No.
You need to learn how it works.
Its an open repo.
If you do not accept that then do not use it.
Yeah because you can read the source of the binaries you are getting from piratebay. ‘/s’
Statements like these are invariably from people unfamiliar with the things involved.
But if you dont like the AUR, or are unwilling to be responsible for your use of it, then simply do not use it.
CachyOS does have a small writeup
AUR Safety - Quick Checklist for CachyOS Users | CachyOS
use brain.exe before you install anything from the AUR. The first infected packages have been:
librewolf-fix-bin
firefox-patch-bin
zen-browser-patched-bin
If you use your brain, then you will notice:
1.) never ever install bin packages from the AUR
2.) those browser are available from the cachy repos, so no need to install them from the AUR
the last detected infected packages are Chrome packages. Chrome is only directly available from google, so this should ring your alarm bells as well.
And how well that works
Link
Personally, I don’t trust these “protective” measures. I ran Windows the last ~8 years without any virus scanner apart from that stupid Windows Defender that
slows down every file operation, and I never had any problems. Then again, I don’t blindly install everything I find on the web ![]()
Joking aside, a healthy distrust towards AUR is in order, just don’t blindly trust these packages…
Simple solution: don’t use the AUR. If the risk to leave your house is unacceptable because of a burglar going around, don’t leave your house.
This is a terrible advice. This way everything can be easily undermined.
No, they are not. The build process is vetted - well hopefully at least trusted. I doubt that anybody at cachy reads through the source-code of all the packages they ship. And that does esp. apply to AUR packages provided by cachy from their repos.
It’s a big chain of trust. Trust-turtles all the way down. Eyeball Mark 1 security.
We can argue about the chances etc. but “the packages are vetted” is one the weakest arguments possible against sandboxing.
But the Arch repositories are vetted.
Cachys few additions in their own repositories, that are not already Arch packages simply being rebuilt, should be .. certainly that is the assumption any user would make.
If they are not and Cachy just blindly builds AUR (or any other random) packages then that would be a serious concern that should be changed immediately.
You might consider ‘but they are vetted’ to be a weak argument against default or extensive sandboxing but it was only one among many. And its as a direct answer to the specific concerns raised by this query - which was about unvetted AUR packages.
And if we think the Arch Repos have no more scrutiny over them than the AUR does then there has been some sort of misunderstanding.
This is a terrible advice.
I agree. It is based on the comment that the “current situation is unacceptable”. 1 person making such a statement will not make much of a difference, I am afraid, as it does not really add any value.
OTOH, one can always whine about an unacceptable situation as that is like letting off steam.
something like Google Play has
We absolutely do NOT want something like Google Play. Google Play is not there to protect you from malicious software.
e.g.: Hundreds of Malicious Google Play-Hosted Apps Bypassed Android 13 Security With Ease
It is there to control users and allow Google to datamine users under the guise of protecting them and also allow Google to monopolise the Android system even more than they already do.
I use Linux (and GrapheneOS on my phone) to escape this sort of security-washing that corpos engage in and giving people false senses of security all whist making mega bucks off of their personal data.
Not to mention using OSS makes a lot of what Play is seeming there to do pointless - we can see what’s inside OSS whereas most of the apps on Play Store are closed/proprietary with no way of knowing for sure what they’re doing.
The best protection against malware and scammers is to know what you are using, good tech literacy, only use good sources, use adblockers, and not install random apps to your computer/phone.
My take is, that if you want more “security” then use a debian based or fedora based distro (Mint, Fedora, Nobara, Ubuntu, whatever). Although it is also not perfect there, there is less risk for the uninformed users (not all packages are tested and monitored there also…but then again, also not in the play store.) If you want to stay on arch, just use the cachy repos and what is available there and do not use AUR.
AUR is the wild wild west of repos, community driven, prone to errors and malware. As you could see, it is detected, but not immediately. There is no singular maintainer here and you should know this, before using the AUR! Only use it, if you know what you are doing. Nothing wrong about that for me.
Clamav has one tool here. AUR (en) - aurscan
more details are here: May / AurScan · GitLab
Before compile, this scan can be done for more security.
additional Clamav tools list here: AUR (en) - Packages
Clamav has one tool here. AUR (en) - aurscan
Not from clamav .. just uses clamav.
It also seems to just scan those sources defined in the PKGBUILD after they are downloaded.
So it would neither prevent the attacks shown previously, nor would clamav even scan those as they were actions not in the source array, so it makes their statement
Warning: Will not detect anything sneakier than the recent attempts, such as downloading files not listed as Sources.
sound .. off?
All it does is run a clam scan on downloaded sources. Thats it.
(You could mention the opening where it verifies the sources .. but thats already standard .. if the sums dont match then the install wont happen.)
No way it can do anything about the recent malicious PKGBUILD examples.
Read the damn PKGBUILDs.
This part is right though.
Yes, I even double checked and added my own curl -O ... inside a PKGBUILD and ran their makepkg -f --verifysource .. and nope, doesnt do a darn thing about the curl in the middle of the PKGBUILD.
This script would only catch something that was already defined in the source array and that clamav has definitions for.
Neither of those things are true for the recent malicious PKGBUILDs.