[SECURITY] firefox-patch-bin, librewolf-fix-bin and zen-browser-patched-bin AUR packages contain malware - Aur-general - lists.archlinux.org
lists.archlinux.org

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

  • slackness@lemmy.ml
    2·
    16 hours ago

    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.comEnglish
      1·
      15 hours 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.