Arch Linux verwijdert kwaadaardige overgenomen packages uit gebruikersrepository

Beheerders van Arch Linux hebben drie packages verwijderd uit de zogenaamde Arch User Repository, waaraan de Arch-community software kan toevoegen. Een van de packages, bedoeld voor het lezen van pdf's, verzamelde informatie over systemen.

Uit het recentste bericht op de Aur-mailinglijst blijkt dat het om de packages acroread 9.5.5-8, balz 1.20-3 en minergate 8.1-2 gaat. De commits naar de packages zijn teruggedraaid en het account dat de wijzigingen doorvoerde, is opgeheven, laat Eli Schwartz van het Arch Linux-team weten. In de discussie wordt gesuggereerd dat de packages zijn overgenomen omdat ze de status orphaned hadden, wat betekent dat ze niet meer worden bijgehouden. Er is ook kritiek dat de ernst van het incident zou meevallen als Aur-gebruikers packages niet geautomatiseerd zouden installeren, maar ze eerst zelf zouden inspecteren.

De inhoud van een van de aangepaste packages, acroread, is bekeken door Bleeping Computer. De site schrijft dat het de bedoeling van de software was om een tweede bestand binnen te halen, dat informatie verzamelt over het systeem van de gebruiker. Die informatie stuurde het dan weer door naar de dienst Pastebin met behulp van een eigen api-sleutel. De malware deed daarom in eerste instantie vrij weinig. Er zou geen manier zijn geweest om de malware zichzelf te laten updaten.

De Arch User Repository laat Arch-gebruikers hun eigen software delen met anderen, waarna deze ook in de officiële repository terecht kan komen. Arch Linux is een distributie die de nadruk legt op een minimalistisch en aanpasbaar systeem. Pakketbeheer is mogelijk met de software Pacman.

Reacties (44)

Beetje knullige "malware", zoals ook de analyse van Bleeping Computer al laat zien. Wat ze daar wel gemist hebben, is dat het "~u" script uiteindelijk niks lijkt te kunnen uploaden door een bug: het definieert wel een functie "upload" maar roept later "$uploader" aan - een variabele die nooit ingesteld is. Dat gaat dus niks doen behalve roepen dat 'ie het commando (het te uploaden log) niet kan vinden...

Kortom: vervelend dingetje, maar zelfs al ben je geïnfecteerd geweest dan heb je hooguit wat scripts en een compromised.txt-bestandje op je systeem staan met wat info, verder niks.

Beheerders van Arch Linux hebben drie packages verwijderd uit de zogenaamde Arch User Repository, waaraan de Arch-community software kan toevoegen.

De packages zijn dus niet verwijderd; de commits die de malware introduceerden zijn teruggedraaid. En inderdaad, zoals tszcheetah vermeldt bezit de malware een bug waardoor er dus uiteindelijk nooit informatie is verstuurd. Omdat de malware zichzelf niet kan updaten, is er dus eigenlijk niet zo veel aan de hand.

Er is ook kritiek dat de ernst van het incident zou meevallen als Aur-gebruikers packages niet geautomatiseerd zouden installeren, maar ze eerst zelf zouden inspecteren.

Dus vanaf nu alle packages die je krijgt decompilen en nalezen? Of lees ik het verkeerd?

Dus vanaf nu alle packages die je krijgt decompilen en nalezen? Of lees ik het verkeerd?

Nee, op een productie systeem gebruik je voornamelijk packages uit de officieele repositories.

En alles wat je op een andere manier binnen haalt, wat niet officieele ondersteund wordt, moet je idd extra controleren.

Je gaat toch ook niet als een kip zonder kop het volgende op je systeem doen?
curl -sSL https://example.com/te_gek_script.sh | sh

Vanaf de AUR download je een soort beknopt script (PKGBUILD) waarmee de boel opgehaald en indien nodig gecomplieerd wordt. Je krijgt doorgaans sources, dus je hoeft niet te decompilen voordat je het zou kunnen controleren.

En ja... het is user produced content. Iedereen kan daar iets in zetten. Daarom wil je het ook controleren voordat je het uitvoert. Dat geldt eigenlijk voor alle programmatuur die je van een bron op internet haalt welke je niet expliciet vertrouwd.

[Reactie gewijzigd door Ultraman op 11 juli 2018 11:11]

Maar hoe doe je dat bij Arch? Bij Windows draai je simpelweg Malwarebytes en dan ga je ervan uit dat het ok is als het niets vindt. Is er een dergelijk programma in de Linux-omgeving? Je kan kijken naar andere gebruikers hun ervaringen maar dat geeft geen garantie.

[Reactie gewijzigd door CHBF op 11 juli 2018 14:53]

Tuurlijk, genoeg programma's als ClamAV en rkhunter die scannen op malware. Het is echter zo dat één package meer kan doen dan enkel malware installeren op een systeem. In theorie kan het potentieel je OS/installatie slopen, zie de bekende bumblebee-bug voor een goed voorbeeld.

Die laatste zin geld ook voor MS, daar zijn ook genoeg updates geweest die systemen hebben gesloopt en datzelfde geld voor steam updates. Mocht je dat allemaal niet willen, dan kun je beter geen computer gebruiken.

Een Windows-update van MS zelf heeft twee keer mijn systeem gesloopt. Dat weet ik omdat ik twee keer dezelfde systeembrekende bug (vensters die niet meer normaal werken) had die direct na het herstarten na een Windows update begonnen. Symptomen:
- niet meer op de knopjes van de vensters kunnen klikken
- niet meer de vensters kunnen verplaatsen
- enkel eventjes een normale interactie net na het openen van de task manager (mogelijk doordat je een nieuw venster opent?)

De vreemdste Windows-bug die ik heb gehad. Ja, na X jaar een computer te hebben gebruikt ben je gegarandeerd zulke problemen tegengekomen, ongeacht welk besturingssysteem je gebruikt. Bij Manjaro heb ik inmiddels ook iets te pakken, een of andere update heeft ervoor gezorgd dat je na suspension niet kan hervatten, in eerste instantie crashte het, na nog wat meer updates start de destkop nu met een nieuwe lege instantie (beter dan crashen maar het maakt suspension wel zinloos).

[Reactie gewijzigd door CHBF op 11 juli 2018 14:40]

een of andere update heeft ervoor gezorgd dat je na suspension niet kan hervatten, in eerste instantie crashte het, na nog wat meer updates start de destkop nu met een nieuwe lege instantie (beter dan crashen maar het maakt suspension wel zinloos).

Heb je een resume optie in je kernel command/boot line? Zie "/proc/cmdline" voor info. Die van mij ziet er zo uit:

BOOT_IMAGE=/vmlinuz-4.17.3-200.fc28.x86_64 root=UUID=84943d6a-6739-4c02-8ce9-cfb93455b4eb ro rhgb quiet loglevel=3 rd.udev.log_priority=3 rd.systemd.show_status=false resume=UUID=d16529df-5d62-4874-8287-8136c41e8012 pci=noaer rd.driver.blacklist=nouveau LANG=nl_NL.UTF-8

Waar het belangrijkste stuk dus resume=UUID=d16529df-5d62-4874-8287-8136c41e8012 is. Dit is trouwens mijn swap partitie.

Dit is alles wat er in dat bestand staat:

BOOT_IMAGE=/boot/vmlinuz-4.14-x86_64 root=UUID=8e2bf555-5236-40d8-8841-7e2ae1111c43 rw quiet

Ik draai Manjaro met KDE. Direct na de installatie was het geen probleem, pas na bepaalde updates ging het mis.

[Reactie gewijzigd door CHBF op 11 juli 2018 14:56]

Lees voor de duidelijkheid ook de documentatie in de Arch wiki hierover eens na. Zo te zien mis je de suspend= parameter. Ik ga ervan uit dat ook Manjaro met SystemD werkt?

Manjaro KDE gebruikt SystemD.
Als die parameter daar wel hoort te staan dan is er bij het updaten iets verkeerd gegaan, ik ben daar niet aan gekomen.

[Reactie gewijzigd door CHBF op 11 juli 2018 16:02]

Nee. /proc/cmdline is alleen maar een diagnostisch dingetje, wat niks doet verder. Deze opties worden in /etc/default/grub (geloof ik, paden kunnen afwijken) opgegeven, en elke keer als je een nieuwe kernel installeert worden deze meegenomen ten tijde van je bootloader configuratie.

Nu kan het zijn dat een kernel update (of een systemd update) support voor deze feature introduceerde, maar dat dit niet standaard geconfigureerd word ten tijde van de installatie. Dat was bij Fedora ook niet, dat gaat pas vanaf Fedora 29 standaard worden.

Volgens de Archwiki zou er bij de overgang naar kernel 15.3 problemen zijn waargenomen met suspending maar ik zit op kernel 14.

De Linux kernel is pas bij versie 4.x.y. Ik neem aan dat je 4.15.3 bedoelt? Zover ik weet is voor een distro met systemd de suspend=xxxxxx optie nodig in je bootloader config, wil je goed kunnen suspenden (naar disk). Hybernation werkt sowieso goed, mits genoeg RAM aanweezig.

Ja, 4.15.3 en 4.14

Op Windows zou een malwarebytes deze software ook niet zomaar pakken, tenzij iemand het al een keer ontdekt heeft. Of het gedrag heel toevallig binnen de heuristics valt. Malwarebytes en andere software werken ook gewoon met definitiebestanden die bepalen wat wel en niet slechte software of gedrag is. Op Linux moet je iets meer zelf kijken naar welke processen er draaien en wat voor poorten/verbindingen ze openzetten. Maarja, als je op Windows zerodays hebt, moet je precies hetzelfde doen.

Alle "packages" in de AUR zijn geen binary's maar scripts om resources (code of binary's) op te halen en te compilen tot een tar.xz package. Je kunt precies zien wat elke script (PKGBUILD) precies doet, mits je de moeite neemt het na te kijken.
Voorbeeld van zo'n PKGBUILD: https://aur.archlinux.org...t/tree/PKGBUILD?h=dropbox. Hier kun je welke sources gebruikt worden (en zou je ze na kunnen lopen)

[Reactie gewijzigd door Lacsapix op 11 juli 2018 11:14]

Het klopt niet dat alle packages van sources build, zie de *pakketnaam*-bin die binaries leveren.
Bijvoorbeeld:
https://aur.archlinux.org/packages/visual-studio-code-bin/
https://aur.archlinux.org...kypeforlinux-preview-bin/

Er zijn dan wel nog stappen nodig, maar in feite zijn het bins.

Dat zei ik, Resources is een andere term dan sources, ik snap de verwaring.

Aur packages zijn scriptjes die een pakket bouwen. Voor de meeste software gebruik je de Aur helemaal niet, maar de officieele repositories.

De AUR bevat feitelijk geen packages maar een buildbeschrijving waarmee je je eigen package bouwt. Deze PKGBUILD file is eenvoudige tekst file en de gebruiker wordt geacht deze te controleren voor gebruik.
Gebruik van de AUR is nadrukkelijk voor eigen risico, er zit geen controle op vanuit Arch.

[Reactie gewijzigd door phaedrus op 11 juli 2018 11:11]

Ik gebruik Trizen om te updaten.
Dan komen de PKGBUILD en ander scripts vanzelf voorbij, kan je ze nakijken/aanpassen.

De interessante vraag is nu ofdat Manjaro ook deze packages toestond. Immers houdt Manjaro veel packages een tijdje (naar verluidt zo'n 2 weken) achter om ze te testen, ik weet echter niet of dat dat ook voor de AUR geldt.

De AUR draait op zichzelf, dus Manjaro en Arch hebben toegang tot dezelfde AUR repo. Manjaro had hier dus ook last van.

Verder is dit wel vervelend, maar niet heel spannend. De meeste gebruikers hebben AUR helemaal niet draaien, je moet er best wat voor doen om te gebruiken en daarbij krijg je de nodige waarschuwingen dat het op eigen risico is. Zolang je gewoon binnen de standaard repo's van Arch/Manjaro blijft is er niets aan de hand. Voor 99% van de zaken heb je daar toch genoeg aan.

Je moet de AUR zien als een soort github, daar draaien mooie dingetjes, maar er kan ook troep tussen zitten. Gebruikers kunnen er zelf mee doen wat ze willen.

Mwah, zo lastig is het niet om de AUR te gebruiken, als je bijvoorbeeld een AUR helper zoals yaourt of trizen gebruikt dan is het installeren van AUR packages en het skippen van de waarschuwingen kinderspel. Ik zeg niet dat dit per definitie een goede manier is om AUR packages te installeren maar in de praktijk zie je wel dat deze software gebruikt wordt om het te doen (ik maak mijzelf er ook schuldig aan).

Daarnaast is het ook mogelijk om de AUR te enablen in de gui installer "pamac" in Manjaro, ik weet niet precies in welke maten er dan nog warnings getoond worden omdat ik zelf nooit echt gebruik maak van GUI installers.

Met andere woorden, de AUR kan heel makkelijk en toegankelijk zijn. Daarom vanuit mij het advies: KIJK WAT JE INSTALLEERT!

[Reactie gewijzigd door Archcry op 11 juli 2018 13:04]

Daarom staan er ook tig waarschuwingen zowel op de wiki alsook op AUR zelf: "AUR packages are user produced content. Any use of the provided files is at your own risk."

Het is altijd aan te raden om te checken wat er is veranderd en hoe de source is. Helaas geven, zoals al heel vaak met blogs, verkeerde adviezen en raden ze zelfs nog altijd managers als Yaourt/pacaur aan (zie hier waarom dat geen goed idee is), laat staan meteen gebruikers adviseren een kijkje te nemen in AUR terwijl dit misschien helemaal niet nodig is. Zeker bij beginnelingen is het aan te raden eerst bekend te raken met Arch Linux en goed in te lezen.

Heb zelf ook zorgen om gebruikers die op Ubuntu ook gewoon maar PPA's toevoegen en niet checken of die source wel veilig zijn.

[Reactie gewijzigd door foxgamer2019 op 11 juli 2018 14:27]

Ja of snaps, waar ook gewoon cryptominers in zitten.

Dank je voor het antwoord. Ik heb de AUR wel enabled maar ik let erop dat ik niet iets uit de AUR haal wanneer ik het ook uit de officieële repositories of bij de bron zelf (Waterfox) kan downloaden.

[Reactie gewijzigd door CHBF op 11 juli 2018 14:34]

Arch Linux is een distributie die de nadruk legt op een minimalistisch en aanpasbaar systeem

Die AUR is mijn ogen in strijd met dat minimalistische, ik zie vaak (onervaren) Arch users letterlijk alles uit de AUR trekken, vooral om te 'ricen'. Er zit ook enorm veel rommel in die AUR wat het sowieso een zwakke plek maakt binnen het Arch eco systeem.

Maar wel goed dat ze actief deze rommel hebben verwijderd natuurlijk.

Je kiest er als gebruiker zelf voor om wel of niet de AUR gebruiken. Of dat je een grafische installer of de CLI gebruikt, je weet het altijd of dat de package uit de Arch-repository of uit de AUR komt. Arch is geen systeem wat op n00bs is gericht, ook al is het zeker prima mogelijk voor een n00b om het te te gebruiken. Jouw kritiek zou terecht zijn bij een distro zoals Mint of Ubuntu, zij richten zich op beginnende gebruikers (waarmee ik niet stel dat ervaren gebruikers geen goede redenen kunnen hebben om voor deze distro's te kiezen).
Mijn punt is dat je een bepaalde doelgroep moet kiezen als distro en daaraan je beleid moet aanpassen. Richt je je op beginners dan maak je het n00b-vriendelijk en bescherm je hen tegen mogelijke fouten die ze maken door hun gebrek aan ervaring. Richt je je op meer ervaren Linux-gebruikers dan maak je het zo gemakkelijk mogelijk voor hen om met hun distro te doen wat ze willen, inclusief het compleet verpesten van hun systeem met alle mogelijke risico's (wachtwoorden, e-mail...) vandien.

[Reactie gewijzigd door CHBF op 11 juli 2018 12:07]

Precies dit. Van een gebruiker die vrij veel moeite gedaan heeft om zijn systeem te installeren (over het algemeen is het installeren van Arch wat lastiger dan je normale huis, tuin en keuken distro) mag je verwachten dat hij zelf de verantwoordelijkheid op zich kan nemen welke packages hij wel en niet installeert. De gebruiker kan inderdaad zelf de keuze maken of hij het wel of niet wil gebruiken. In een distributie zoals Ubuntu zou je inderdaad verwachten dat de gebruiker meer geholpen wordt bij het installeren van zijn packages. Daarvoor hebben ze snaps in het leven geroepen. Wel jammer dat deze oplossing juist wel op noobs gericht is en ook niet waterdicht is (cryptominers in snaps).

Ik wist niet dat er gemined wordt via snaps, het zou me niet moeten verbazen.
Ik ben het uiteraard met @analogue eens dat je heel erg voorzichtig moet zijn met via de AUR iets binnen te halen, het is een kwetsbaarheid binnen het systeem. Je moet de afweging maken tussen het aantal gebruikers wat software kan toevoegen - en dus de grootte van de repository - en de veiligheid. Ik download (en installeer als het nodig is) liever software direct van de bron dan via de AUR.

Terzijde, een goed advies om bepaalde zaken (internetbankieren, credit-card, misschien zelfs je e-mail) veiliger te doen is het gebruiken van een aparte USB met daarop een goed dichtgetimmerde Linux-distro die je enkel voor die zaken gebruikt.

[Reactie gewijzigd door CHBF op 11 juli 2018 14:28]

Dat vind ik op zich een zeer zinnige zienswijze, en ik denk ook dat je in dat licht wel een AUR kunt rechtvaardigen. Maar denk ik dat je als poweruser misschien juist wel weer minder behoefte hebt aan zo'n systeem.

Mijn kritiiek is dat de AUR een soort manusje van alles is, er lijkt geen structuur te zijn of enige controle op wat je allemaal aan dependencies binnentrekt. Daar zit mijn inziens een zwakke plek zodra je daar teveel op gaat vertrouwen.
En ja, je hebt gelijk; het gebruik ervan is niet verplicht en je kunt een prima veilig systeem runnen op Arch. Maar op de Arch subreddits en de diverse fora wordt er wel heel snel gesuggereerd om package x uit de AUR te halen.

Ik zou mensen adviseren om daar zeer kritisch mee om te gaan en als je kunt het zelfs te vermijden.

Totaal mee oneens, de AUR is een goeie plek waar nieuwe TU's kunnen worden ge-recruit daarnaast is het juist de open source gedachte om PKGBUILDs te delen.

Het is zeker lekker FOSS, dat is ook het probleem helemaal niet. Maar dat neemt niet weg dat vaak onervaren gebruikers hun systeem bloaten met packages vanuit de AUR, en die zijn helemaal niet in staat om het kaf van het koren te scheiden.

Ik zeg dus ook zeker niet dat het 100% gevaarlijk is en dat er niets goeds uit voort komt.

Dit is zowel minimalistisch en aanpasbaar: de repositories bevatten een goed geteste basis (en meer), maar voor extra aanpasbaarheid is er de AUR, zodat niet iedereen zelf een PKGBUILD hoeft te schrijven voor van alles en nog wat.

Onervaren gebruikers bij de hand nemen is dan juist weer niet een doel van Arch, dus helemaal geen probleem. Iedereen is in staat om te leren wat een malafide PKGBUILD is, dat is vaak heel simpel na te gaan (tis gewoon een bash scriptje).

Ik snap de nieuwswaardigheid van dit artikel trouwens niet echt, overal op de AUR staat dat het niet veilig is en dat iedereen zelf moet checken wat ie binnenhaalt. Het wordt bijna neergezet alsof Arch "gehackt" is oid.

Leuk dat je de AUR over een kam scheert, kan je ook een voorbeeld geven van pakketten die in jouw ogen waardeloos zijn? Vergeet ook niet dat in AUR pakketten zitten die om licentie redenen niet in de officiële repo's mogen worden aangeboden.

Ik scheer helemaal niets over een kam volgens mij? OOk heb ik het woord waardeloos nergens genoemd.

Nog een keer dan: het grote probleem is dat de AUR een grote vergaarbak is van allerlei packages. Ik zeg daarom expres niet dat de AUR per se slecht is, maar dat er wel een bepaald risico huist in dat systeem. Daarnaast zie ik veel Arch users in mijn omgeving met redelijke bloated systemen omdat ze dus veel vanuit die AUR halen.

Concreet heb ik dus niet iets tegen packages in de AUR of de AUR zelf, maar probeerde ik wel enkele, in mijn ogen, risicovolle punten aan te wijzen die met het systeem samenhangen.

Tenslotte, ja ik heb zelf ook langere tijd Arch gedraaid, nu al enkele jaren niet meer. maar Ik heb dus ook ervaren hoe het is om met de AUR te werken.

Ben zeker het met je eens dat veel gebruikers een alternatief in de repo's kunnen gebruiken i.p.v. in AUR.
Ik haal echter ook veel uit AUR en die zijn niet allemaal bloated, er is ook genoeg aanbod van trusted/developers en ook pakketten die worden verplaatst vanuit de repo's naar AUR.

Je hebt dus zeker gelijk dat AUR-packages een risico met zich meebrengen, maar ook genoeg packages die wachten om naar de community repo verplaatst te worden.

Ik vind het zelf jammer dat dit nieuws zo breed word uitgemeten overal, de AUR is unsupported en iedereen kan er PKGBUILD's uploaden. Het feit dat er bijna geen malware op zit vind ik al verbazingwekkend

merendeel van de users vindt het ook geen bezwaar om '$ sudo curl http://www.asdas.com/asdsa.sh | sh' uit te voeren zonder eerst te kijken wat er gebeurt..

Dat is vrijwel niet oplosbaar

Gedoe met het overnemen van bestaande maar orphaned packages is helaas een fenomeen waar wel meer package repositories last van hebben / gehad (npm bijvb). Het zal ook wel lastig blijven om er iets aan te doen aangezien het grotendeels gebouwd is op vertrouwen.