Arch Linux AUR Repository Found to Contain Malware

Arch Linux AUR Repository Found to Contain Malware

The Arch Linux user-maintained software repository called AUR has been found to host malware. The discovery was made after a change in one of the package installation instructions was made. This is yet another incident that showcases that Linux users should not explicitly trust user-controlled repositories.

AUR User-Maintained Arch Linux Repository Contaminated with Malware




Linux users of all distributions have received a major warning not to explicitly trust user-run software repositories following the latest incident related to Arch Linux. The project’s user-maintained AUR packages (which stands for “Arch User Repository”) have been found to host malware code in several instances. Fortunately a code analysis was able to discover the modifications in due time.

The security investigation shows that shows that a malicious user with the nick name xeactor modified in June 7 an orphaned package (software without an active maintainer) called acroread. The changes included a curl script that downloads and runs a script from a remote site. This installs a persistent software that reconfigures systemd in order to start periodically. While it appears that they are not a serious threat to the security of the infected hosts, the scripts can be manipulated at any time to include arbitrary code. Two other packages were modified in the same manner.

Related Story: Gentoo Linux GitHub Hacked via Password Guessing

Following the discovery all dangerous instances were removed and the user account suspended. The investigation reveals that the executed scripts included a data harvesting component that retrieves the following information:

  • Machine ID.
  • The output of uname -a.
  • CPU Information.
  • Pacman (package management utility) Information.
  • The output of systemctl list-units.

The harvested information was to be transferred to a Pastebin document. The AUR team discovered that the scripts contained the private API key which shows that this was probably done by an inexperienced hacker. The purpose of the system information remains unknown.




The confirmed list of affected packages includes the following AUR entries:

  • acroread 9.5.5-8
  • balz 1.20-3
  • minergate 8.1-2

There are several hypotheses that are currently considered as possible. A reddit user (xanaxdroid_) mentioned online that “xeactor” has posted several cryptocurrency miner packages which shows that infection with them was a probable next step. The obtained system information can be used to choose a generic miner instance that would be compatible with most of the infected hosts. The other idea is that the nick name belongs to a hacker group that may target the infected hosts with ransomware or other advanced viruses.

Whether or not Linux users use Arch Linux they should double check if any user-maintained repositories that they use are trustworthy. This incident show once again that security cannot be guaranteed. A comment made by Giancarlo Razzolini (an Arch Linux trusted user) reads that explicitly trusting AUR and using helper applications is not a good security practice. In response to the mailing list announced he posted the following reply:

I’m surprised that
this type of silly package takeover and malware introduction doesn’t happen more often.

This is why we insist users always download the PKGBUILD from the AUR, inspect it and
build it themselves. Helpers that do everything automatically and users that don’t pay
attention, *will* have issues. You should use helpers even more so at your risk than
the AUR itself.

Timeline of Arch Linux AUR Incident Response

  • Sun Jul 8 05:48:06 UTC 2018 — Initial Report.
  • Sun Jul 8 05:54:58 UTC 2018 — Account suspended, commit reverted using Trusted User privileges.
  • Sun Jul 8 06:02:08 UTC 2018 — The additional packages were fixed by the AUR team.

Users of all Linux distributions should be well aware of the risks associated with installing software from repositories that are not maintained directly by their direct maintainers. In some cases they do not bear the same commitment and responsibility and it is much more likely that a malware infection can spread and may not be addressed in due time.

Note: The article has been updated with a timeline of the events.

Martin Beltov

Martin graduated with a degree in Publishing from Sofia University. As a cyber security enthusiast he enjoys writing about the latest threats and mechanisms of intrusion.

More Posts

Follow Me:
TwitterGoogle Plus

16 Comments

  1. somebob

    So erm the list of packages affected might be nice in include.

    Reply
    1. Martin Beltov (Post author)

      Hey somebob,

      I followed the incident on the official Arch linux mailing list and the mentioned packages are “libvlc.git” and “acroread.git”. The developers state that two other packages besides “acroread” have been manipulated, a later email mentioned “libvlc”.

      Look at the link in the article to access the discussion if you are interested in how the team handled the situation in detail.

      Reply
  2. neithere

    Doesn’t “explicit trust” mean the desired behaviour, i.e. a user’s informed decision about a given package, rather than “implicit trust”, i.e. the lack of user’s decision regarding a particular package but a general trust to all of them?

    Reply
    1. Martin Beltov (Post author)

      I guess you’re right!

      Reply
  3. nobody

    Somebody was just questioning the libvlc source. If you read the later emails it was pointed out that the url is part of pacman-mirrorlist.

    Reply
    1. Martin Beltov (Post author)

      Thanks for clarifying this.

      Reply
  4. Marcin Mikołajczak

    Probably every single one AUR helper informs us that we should read PKGBUILDs, so being infected by malware at this layer means that somebody doesn’t treat security seriously…

    Reply
    1. Martin Beltov (Post author)

      True, hopefully this incident will help to raise awareness.

      Reply
  5. Roel Brook

    6 minutes is a pretty good response time.

    My guess would be the output could be used for a more targeted attack against the more powerful machines. If you can tell most of the machines with 32 CPU cores have some package installed, you know which one you should hijack next.

    It’s not so much a trust in the AUR system itself. It’s more trusting the maintainer(s). When a package switches maintainer, you should be temporary on guard.

    Would be a nice addition to youart.

    Reply
    1. Martin Beltov (Post author)

      THE AUR trusted users are awesome IMHO!

      Reply
  6. Condor

    Hence why you may want to check the PKGBUILD every now and then before installing or upgrading AUR software. User-maintained repositories can sometimes hold packages that were built by jackasses, no shit Sherlock!

    Reply
    1. Martin Beltov (Post author)

      True, but not everyone can understand the variables and code in the PKGBUILD files.

      Reply
  7. KEK

    That’s why I can reccomend using “trizen” over “yaourt”: I get all the information first. (Also they did their escaping routines right).

    Reply
    1. Martin Beltov (Post author)

      Thanks for the recommendation, I have always used “yaourt” as I am accustomed to it.

      Reply
  8. Phoenix591

    True, but it is straightforward bash concentrated almost entirely in a single file (I much prefer it to debian format in that regard), and the only official direction on how to use the AUR has had nice red warnings saying check for potentially malicious code (and if unsure ask on thr forums and/or mailing list) for years

    Reply
    1. Martin Beltov (Post author)

      I agree that the Arch Linux user community is very reliable. The AUR repository is awesome as it contains many packages that cannot be included in the main repos.

      The wiki gives a detailed overview on how it is managed, I hope that the “acroread case” will set the necessary warning lights to new users in handling the user-maintained packages with greater care.

      KEK posted a comment here stating that the “trizen” helper application shows detailed PKGBUILD info by default.

      Reply

Leave a Comment

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

Share on Facebook Share
Loading...
Share on Twitter Tweet
Loading...
Share on Google Plus Share
Loading...
Share on Linkedin Share
Loading...
Share on Digg Share
Share on Reddit Share
Loading...
Share on Stumbleupon Share
Loading...