Az Arch Linux fejlesztői szerint sikerült eltávolítaniuk az ismert rosszindulatú AUR-commitokat, de az incidens nagyobb méretűnek bizonyult a korábbi becsléseknél. A korábbi cikkünkben még 400 fölötti érintett AUR-csomagról számoltunk be, a későbbi vizsgálat azonban 1621 érintett csomagot tárt fel.
Az eset az Arch User Repositoryt érintette, vagyis nem az Arch Linux hivatalos bináris csomagtárolóit. Az AUR-ban felhasználók által karbantartott PKGBUILD fájlok és kapcsolódó install szkriptek találhatók, amelyek alapján a csomag a felhasználó gépén fordul le. Emiatt a kockázat nem pusztán abból adódott, hogy egy csomag szerepelt az érintett listában, hanem abból, ha a kompromittált időszakban lefutott-e a módosított build- vagy install-folyamat az Arch Linux telepítésünkön.
A nap elején még több mint 400 érintett csomagról szóltak a jelentések, majd néhány órával később ez a szám nagyjából 900-ra emelkedett. A legutóbbi állapotlista szerint 1621 AUR-csomag érintett az incidensben. Az Arch fejlesztői az incidenssel foglalkozó threadben azt írták, hogy törölték az összes általuk ismert rosszindulatú commitot.
A támadás az AUR nyitott karbantartási modelljét használta ki. A veszélyt azok a csomagok jelentették, amelyeknél a PKGBUILD vagy az install fájl külső csomagkezelőkön keresztül kártékony komponenseket húzhatott be. Ez főleg akkor jelenthetett kockázatot, ha a felhasználó AUR-helperrel frissített, és ellenőrzés nélkül fogadta el a build-fájlok módosításait.
Azoknál az Arch Linux telepítéseknél, ahol az érintett AUR-csomag már régebb óta telepítve voltak, és a kompromittált időszakban nem került frissítésre, ott minimális a fertőzés esélye. Ezt elsősorban a pacman naplójából és az AUR-helper cache-éből lehet ellenőrizni, mert ezekből kiderülhet, hogy az adott gépen lefutott-e a módosított build- vagy install-folyamat. Ha egy érintett csomag már korábban felkerült a rendszerre, és azóta nem frissült vagy nem épült újra, akkor a puszta jelenléte önmagában nem bizonyít fertőzést.
A telepítés vagy frissítés dátumát könnyedén ellenőrizhetjük a pacman naplójából:
$ grep -i "libgdata" /var/log/pacman.log 16:13:33
[2024-09-20T18:30:33+0200] [ALPM] installed libgdata (0.18.1-3)
[2025-05-12T11:19:16+0200] [ALPM] upgraded libgdata (0.18.1-3 -> 0.18.1-4)
[2026-03-03T19:14:11+0100] [ALPM] upgraded libgdata (0.18.1-4 -> 0.18.1-5)
[2026-06-13T16:12:56+0200] [PACMAN] Running 'pacman -R libgdata'
[2026-06-13T16:12:58+0200] [ALPM] removed libgdata (0.18.1-5)A paru és yay AUR-helperek cache-ében az alábbi paranccsal kereshetünk rá a jelenleg ismert gyanús csomagok meglétére:
YAY esetén:
$ grep -RInE "atomic-lockfile|js-digest|lockfile-js|bun install|npm install" ~/.cache/yay/csomagnév 2>/dev/nullParu esetén:
$ grep -RInE "atomic-lockfile|js-digest|lockfile-js|bun install|npm install" ~/.cache/paru/clone/csomagnév 2>/dev/nullAz ismert rosszindulatú commitok törlése nem teszi automatikusan biztonságossá azokat a rendszereket, ahol a kompromittált build- vagy install-folyamat már lefutott. Aki a kérdéses időszakban AUR-csomagokat frissített, annak érdemes átnéznie a pacman naplóját, az AUR-helper cache-ét, valamint az érintett csomagok PKGBUILD és install fájljait. Gyanús találat esetén az érintett csomag és a helyi build-cache törlése csak az első lépés. Ha a kártevő lefutott, a fejlesztői tokeneket vissza kell vonni, az SSH-kulcsokat le kell cserélni, a böngészőben tárolt munkameneteket pedig a kapcsolódó szolgáltatások felületén érvényteleníteni kell. Súlyosabb esetben a rendszert érdemes tiszta telepítőből újrahúzni, vagy biztosan tiszta, korábbi mentésből visszaállítani.
A komprommitált csomagok meglétének ellenőrzéséhez készítettünk egy scriptet, amelyet a PingvinBázis Github fiókjáról tölthettek le innen, vagy a git clone https://github.com/pingvinbazis/pb_aur_package_check.git paranccsal leklónozva. majd futási jogokat szükséges adni chmod a+x aur_check.sh paranccsal. Ezt követően futtassuk le a ./aur_check.sh paranccsal.
