GitHub haalt repository van xz offline na vinden van malware

GitHub heeft de centrale repo van xz offline gehaald. Volgens het platform overtrad xz de algemene voorwaarden. Eerder deze week bleek er malware te worden verstuurd met de compressietool, waardoor veel Linux-distro's kwetsbaar werden.

De repo, tukaani-project/xz, is niet meer te vinden op GitHub. Het platform zegt dat het de repository zelf heeft uitgeschakeld omdat die GitHubs gebruikersvoorwaarden zou overtreden, al geeft het daar geen details over. GitHub staat malware niet toe.

De compressietool xz kwam vrijdag in het nieuws toen bleek dat die mogelijk malware bevatte. In versies 5.6.0 en 5.6.1 lijkt een backdoor te zitten waarmee het mogelijk is om onder andere ssh-verbindingen over te nemen. Daar is nog veel niet over bekend, maar het heeft er inmiddels alle schijn van dat iemand malware in de repo heeft geplaatst in de hoop die naar meerdere Linux-distro's te verspreiden.

Reacties (83)

[RobertMe]

lijkt een backdoor te zitten waarmee het mogelijk is om onder andere ssh-verbindingen over te nemen. Daar is nog veel niet over bekend

Er is niet veel over bekend, maar wel meer dan dit. Het gaat namelijk niet over het "overnemen" van SSH verbindingen, maar over een backdoor met een RCE, Remote Code Execution, mogelijkheid. Als ik het goed begrepen heb wordt de logica die de public/private key pair valideert overschreven (zogenaamde "monkey patching", waarbij de mogelijkheid wordt geboden / gebruikt om @runtime een bestaande functie te overschrijven / herleiden naar een andere functie, in dit geval wordt dus de "goede" validatie functie herleid naar een "kwaadaardige"). Waarbij er een specifieke public key wordt ondersteund en het resterende deel van de "payload" aan een `system()` call wordt gegeven. Hierdoor kan dus de eigenaar van de bijbehorende private key naar alle waarschijnlijkheid op (alle) "besmette" systemen naar eigen inzicht een willekeurig stuk code / shell script uitvoeren. Waarbij die code (/dat script) "uiteraard" wordt uitgevoerd met de rechten die sshd heeft, zijnde root (sshd draaien als een andere user dan root is (zo goed al) onmogelijk).

En doordat deze RCE alleen mogelijk is met de juiste public/private key pair, en de code zwaar obfuscated is is er verder nog geen exacte duidelijkheid over hoe de backdoor in elkaar zit en welke mogelijkheden deze biedt. Omdat de backdoor dus alleen gebruikt / uitgevoerd kan worden door de eigenaar van de private key.

[Reactie gewijzigd door RobertMe op 23 juli 2024 08:46]

[ExpectedError]

Dit gaat een stuk verder dan alleen de exploit zelf. Het proces van hoe dit kon gebeuren is eigenlijk net zo belangrijk. Zie
https://boehs.org/node/ev...now-about-the-xz-backdoor

[Nark0tiX]

Git blame?

[ExpectedError]

Ik ben zelf door een aantal commits gegaan. Voorbeeldje van een van de commits die ik zelf verdacht vond https://git.tukaani.org/?...1307644efdb58db2c422d9ba7

Waarom vond ik de commit verdacht: Er gebeurt te veel wat niet verklaard word in de commit message. Ik ben later geattendeerd op het feit dat een punt is toegevoegd is aan de check_c_source_compiles code. Die punt zorgt er voor de dat security sandbox feature altijd uit staat.

[MeMoRy]

Ik had dat gelezen in de analyse, maar kon het niet vinden...
Echt 10x moeten doorlezen. Daaaamn goed verstopt. Je moet echt weten wat je leest.

[RobertMe]

Het was niet goed verstopt. Staat in plain sight. Deze persoon had er ook voor kunnen kiezen om bv een non breaking space of het cyrillische teken dat verdacht veel op een c lijkt (als in: het is gewoon hetzelfde teken, alleen een andere "code" / unicode). Dan is het pas goed verstopt, want zeker zo op een website lees je er direct overheen. In ieder geval VS code schijnt unicode (/niet ANSII?) tekens pontificaal te highlighten, daarin zou het wel opvallen.

Daarnaast staat dat stuk C code 2x in die commit. 1x in de CMakeLists.txt en 1x in de configure.ac. De eerste is uiteraard van cmake, de tweede van autotools. En de eerste bevat die additionele punt, de tweede niet. Bij een build uitgevoerd met autotools zou de detectie dus correct moeten werken (of in ieder geval zal de fout daar niet in die, daar afwezige, punt zitten). En in ieder geval Arch Linux (ok, niet getroffen waarschijnlijk doordat er checks in zitten op of het een RPM of Deb build is) gebruikt autotools (./autogen.sh, ./configure, make). En afgaande op het "script" dat Debian gebruikt lijkt daar ook autotools gebruikt te worden en niet cmake (RPM based / van Fedora heb ik niet opgezocht). Die punt lijkt dus alleen effect te hebben op het build systeem dat in ieder geval niet door Arch & Debian gebruikt wordt.

Verder kan het dus ook gewoon een onschuldig foutje zijn. I.t.t. tot het gebruik van bv een non-breaking space of die cyrillische "c" dus, die type je niet "per ongeluk".

[Goldwing1973]

Wauw, die stond wel heel goed verstopt, moest 5x lezen om 'm te vinden

+ #include <sys/prctl.h>
+.
+ void my_sandbox(void)

[ddofborg]

Kan iemand uitleggen wat dit punt aan het begin van de regel doet? Is dat niet gewoon een compile error? Ben zeker geen ervaren C programmeur, maar ken dit niet.

[TSshadow]

Na even googlen:

There's a dot at the start of the middle line here (in CMakeLists.txt)
+ #include <sys/prctl.h>
+.
+ void my_sandbox(void)
A dot is not allowed at this position in C code, so compilation of this program will fail. This means that the variable HAVE_LINUX_LANDLOCK will always be set to false, regardless of whether the platform has Landlock (a Linux security system). This meant that xz never used Landlock, bypassing a security measure that (I assume) would have caught or prevented the exploit.

[The Zep Man]

Daar is nog veel niet over bekend, maar het heeft er inmiddels alle schijn van dat iemand malware in de repo heeft geplaatst in de hoop die naar meerdere Linux-distro's te verspreiden.

De malware was over een langere periode toegevoegd en was afhankelijk van meerdere componenten. In de huidige vorm is het onwaarschijnlijk dat het misbruikt werd, en het lijkt erop dat de malware "te vroeg" was gevonden.

Een breder vraagstuk is hoe het met andere software zit. Deze xkcd is relevant. Nu was het voor dit specifieke incident een probleem dat er ruimte is voor obfuscatie door de manier waarop configure-bestanden worden gegenereerd en tests worden geschreven voor C(++)-projecten. Het kan de moeite lonen om over te stappen naar talen die minder ruimte hebben voor dergelijke obfuscatie.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:46]

[MneoreJ]

Het is gevaarlijk, ik zou willen zeggen heel gevaarlijk, om te denken dat een of andere technische oplossing hier het ei van Columbus is. Het is techneuten eigen om te denken dat de technologie het begin en het eind van alles is (gegeven alle mensen die nog steeds roepen dat het allemaal de schuld is van systemd omdat dat zo complex is, wat een hele slechte take is), maar in dit geval hebben ook en vooral veel processen gefaald waardoor deze hacker zich in een vertrouwd project kon wurmen en via daar weer in een kritieke service. Het idee dat je met taal of technologie X de boel intrinsiek veiliger gaat maken omdat vector Y daar niet mogelijk is (of lastiger) betekent alleen maar dat je de volgende generatie slimmerds moet afwachten.

Dat er bij de tests een binary blob zat om de compressie te testen zou ook in een Go project niet per se de wenkbrauwen hebben doen fronsen. En ook in een Go project zou, als er nog maar twee actieve committers over zijn, waarvan een de hacker, heel makkelijk wat obfuscated code gestopt kunnen worden die op het eerste gezicht alleen onhandig lijkt, maar onder water een exploit is. Niet via Autoconf, maar dat hoeft ook niet.

[Reactie gewijzigd door MneoreJ op 23 juli 2024 08:46]

[The Zep Man]

Het is gevaarlijk, ik zou willen zeggen heel gevaarlijk, om te denken dat een of andere technische oplossing hier het ei van Columbus is.

Wat de reden is dat ik nergens omschrijf dat wat ik voorstel de perfecte oplossing is.

Dat er bij de tests een binary blob zat om de compressie te testen zou ook in een Go project niet per se de wenkbrauwen hebben doen fronsen.

Ik vind van wel. Je kan ook (reproduceerbaar) een binary blob genereren. Kost minder code, het genereren zorgt voor minder ruimte voor misbruik, en het kan overzichtelijker geïmplementeerd worden.

Niets is perfect. Ruimte voor waar men brabbelcode verwacht kan wel gereduceerd worden.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:46]

[RobertMe]

Ik vind van wel. Je kan ook (reproduceerbaar) een binary blob genereren.

Iets dat natuurlijk ook perfect bij het huidige project had gekund. Sterker nog. Eerst was er een magische blob, maar die werkte niet altijd goed (5.6.0). Vervolgens is die magische blob bijgewerkt (5.6.1) met als omschrijving "de eerste versie kon niet reproduceerbaar worden gegenereerd, nu wel, door het gebruik van een seed". Volgens de woorden van de commit was die dus al gegenereerd op een reproduceerbare manier, en nu is er achteraf natuurlijk ook al de roep dat "als dat waar was" (was het uiteraard niet) de blob met een script gegenereerd had moeten worden, en dat script dus in de repo staat (en de blob niet) en onderdeel van het build / test proces is.

Of sterker nog: de roep is gewoon "sta geen (binary) blobs toe, in welk project dan ook, en laat die blob als die nodig is dan reproduceerbaar genereren door een script".

[latka]

"sta geen binary blobs toe": dan kun je de nvidia driver ook niet meer installeren...

[RobertMe]

In de repository, en laat de Nvidia driver nu niet echt in een (public) repository leven Waarbij het dus ook de keuze van de gebruiker is om wel of niet closed-source software te installeren.

Zeg dan de AMD (GPU) drivers Die zit volgens mij ook vol met binary blobs, maar leeft wel in de Linux kernel repository (en dus "open source").

[The Zep Man]

Zeg dan de AMD (GPU) drivers Die zit volgens mij ook vol met binary blobs, maar leeft wel in de Linux kernel repository (en dus "open source").

De drivers in de kernel zijn volledig opensource, ook die van AMD. Mogelijk zitten er binary blobs in linux-firmware, wat een apart pakket betreft. Die worden door opensource code naar de GPU gestuurd om uit te voeren.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:46]

[CAPSLOCK2000]

"sta geen binary blobs toe": dan kun je de nvidia driver ook niet meer installeren...

Dat is waarom de LInux community al jaren over NVidia aan het klagen is. De halve (Linux)wereld wordt gedwongen om binary blobs te accepteren omdat NVidia z'n drivers geheim houdt. Ik vind mijn security belangrijker dan het bedrijfsgeheim van NVidia.

Ik snap dat er allerlei ingewikkelde belangen spelen (en dom gedoe als intellectueel eigendom) en NVidia is ook niet de enige die het zo oplost, maar het blijft problematisch, zeker omdat problemen bij de gebruikers terecht komen, niet NVidia.

[ari3]

Tja, de Nvidia drivers zijn closed source, maar de firmware blobs van heel veel hardware ook. GPU's van AMD hebben een firmware blob nodig. Net als de CPUs van Intel en AMD, die hebben ook een firmware (microcode) blob nodig. Die kan de Linux community ook niet valideren of reviewen, laat staan aanpassen.

Eigenlijk moet er wetgeving komen die de specificaties, sleutels en tooling nodig om firmware te schrijven verplicht openbaar maakt. De bedrijfsgeheimen van Intel en AMD zijn een veiligheidsrisico en daarom moet firmware onafhankelijk gevalideerd kunnen worden.

[MneoreJ]

Of sterker nog: de roep is gewoon "sta geen (binary) blobs toe, in welk project dan ook, en laat die blob als die nodig is dan reproduceerbaar genereren door een script".

Je vergeet het kritieke puntje: "en zorg dat dat script gereviewed is door mensen die begrijpen wat het doet", wat in dit project nou net niet meer gebeurde.

Dat lijkt voor de hand liggend, maar uiteraard kun je met een voldoende subtiel script nog steeds perfect "testdata" genereren die stiekem gewoon een exploit blijkt. Dat het dan niet meer "test.blob" heet maar netjes "generate-test-regression-pr3234.sh" is alleen leuk voor de groene vinkjes.

[RobertMe]

Uiteraard

Maar als de code bekend was die de exploit blob genereerde dan kon die wel nog steeds ge-reverse-engineerd worden nu, achteraf (ook als die niet goed genoeg gereviewed was). Terwijl er nu letterlijk alleen de blob is en het ontleden van deze blob vele malen moeilijker is. Uiteraard dus ook met het idee dat het script dat de blob genereert niet ook weer blobs of soortgelijke mag bevatten. (anders kun je de blob in meerdere delen splitsen en ze dan aan elkaar plakken en klaar )

[MneoreJ]

Ik vind van wel. Je kan ook (reproduceerbaar) een binary blob genereren.

Ja, dat kan. Maar het is allesbehalve lastig om je voor te stellen dat iemand een kritieke bug heeft gevonden (of beweert te hebben gevonden) die specifiek alleen optreedt als een bepaalde bytereeks gecomprimeerd/gedecomprimeerd wordt, en het blijkt lastig om dat te reduceren naar een simpelere repro. Dus check je dat problematische stukje even in als bestand zodat je dat als regressietest op kan voeren. Verdient geen schoonheidsprijs, maar dat doen wel meer dingen niet als we druk aan het ontwikkelen zijn, right?

In een project met 20 andere mensen die de PR reviewen komt daar dan misschien toch nog een betere oplossing uit, maar in een project dat niemand meer over heeft voor een review kan zoiets gewoon lijken op roeien met de riemen die je hebt.

[RobertMe]

Maar het is allesbehalve lastig om je voor te stellen dat iemand een kritieke bug heeft gevonden (of beweert te hebben gevonden) die specifiek alleen optreedt als een bepaalde bytereeks gecomprimeerd/gedecomprimeerd wordt, en het blijkt lastig om dat te reduceren naar een simpelere repro

Ik weet even niet om welke van de twee blobs het gaat (er was een "good" en een "bad"). Maar dit kan dan eigenlijk toch wel weer simpel in de "is het de 'bad' blob dan kan die gegenereerd worden (dan doet de inhoud er niet toe), is het de 'good' blob dan kun je tijdens reviewen ook kijken of dat ding daadwerkelijk uit te pakken is'.

Even los van "tijd" en daarmee aandacht die aan reviews wordt gegeven. Waarbij ik ook niet weet of deze bad actor uberhaupt nog code via PRs deed toevoegen of dat die gewoon rechtstreeks op master zat te pushen zonder dat er uberhaupt een review nodig was.

[MneoreJ]

Tja, zelfs al was er een review nodig (en volgens mij was dat al niet meer het geval, deze gast was gewoon beheerder geworden) als een project nog maar 2 mensen over heeft dan is dat natuurlijk ook bijna een wassen neus geworden. Hier was ook een stuk social engineering bij waarbij de solo maintainer onder druk gezet werd om "hulp" te accepteren van de hacker die het allemaal wel even zelf ging regelen. Als zo'n persoon eenmaal "vertrouwd" is wordt het erg makkelijk om de wijzigingen te laten rubberstampen zelfs al komt er een review. Dat is zelfs zo als er nog een handjevol mensen over is die in principe een fatsoenlijke review zouden kunnen doen, dan moet je de boel alleen wat beter verbergen.

Ik heb het dan nog niet eens over het doembeeld van spookrepositories met 50 actieve contributors, die stiekem allemaal AI bots onder beheer zijn die elkaars "verbeteringen" enthousiast accepteren. Nu is iedereen natuurlijk bedacht op de wat minder actieve projecten, maar dat is allesbehalve het enige waar we aan moeten denken voor de supply chain.

[Reactie gewijzigd door MneoreJ op 23 juli 2024 08:46]

[CAPSLOCK2000]

Tja, zelfs al was er een review nodig (en volgens mij was dat al niet meer het geval, deze gast was gewoon beheerder geworden) als een project nog maar 2 mensen over heeft dan is dat natuurlijk ook bijna een wassen neus geworden. Hier was ook een stuk social engineering bij waarbij de solo maintainer onder druk gezet werd om "hulp" te accepteren van de hacker die het allemaal wel even zelf ging regelen. Als zo'n persoon eenmaal "vertrouwd" is wordt het erg makkelijk om de wijzigingen te laten rubberstampen zelfs al komt er een review.

Dit stukje wordt erg onderschat. xz is kritieke infrastructuur maar niemand wil er geld of tijd in steken. De halve wereld gebruikt het en jarenlang was er maar 1 persoon eigenlijk al het werk deed. Als iemand hulp aanbiedt wordt die uiteraard enthousiast geaccepteerd. Een project dat zo krap zit zal weinig prioriteit geven aan opstellen van procedures en verificaties. Het is geen excuus maar wel begrijpelijk.

Wat ik echt een enge gedachte vind is dat dit plaats heeft kunnen vinden terwijl alle code en repositories openbaar zijn. Achter gesloten deuren gaat het natuurlijk nog veel makkelijker. Dit project werd beheerd als hobbyproject, dus met liefde en enthousiasme. Bij bedrijven zitten een ook een hoop "matig" gemotiveerde programmeurs die zich er zo makkelijk mogelijk van af maken en die nooit gecontroleerd worden en wiens code ook nog geheim blijft. Daar moet gewoon ontzettend veel gebeuren wat niemand ooit ontdekt.

Dit probleem is ook past naar boven gekomen na een lange speurtocht door de code omdat iemand merkte dat inloggen langzaam was. Bij een gesloten systeem zou je dat waarschijnlijk niet eens proberen op te sporen. Als je de bug al vindt kun je er toch niks aan doen (tenzij je doel is om security exploits te schrijven).

[Hans1990]

Je kan ook (reproduceerbaar) een binary blob genereren.

Een binary blob bedoeld als code of data?

Code zou geen enkel excuus voor moeten zijn. Het project is open source of niet. Een binary blob moet een hele goede reden hebben om bijgevoegd te worden.

Binary blobs voor data kan ik echter wel voorstellen. Als je werkelijk "alle" mogelijke inputs/formats wilt testen, waaronder corrupted streams of edge-cases, dan is binary blob wel verreweg de makkelijkste manier om die te 'genereren'.

Het is zeker niet 'fout' om je eigen encoder te gebruiken om ook de decoder te testen, maar in veel gevallen zie ik dat als happy-path integratie tests. Juist unit-tests die afwijken van happy path testing zijn effectief. Door bepaalde streams te 'hard coden' vermijd je dat (alle) unit tests richting integratie tests gaan, want dat bemoeilijkt het zoeken naar de test met het kernprobleem.

[downtime]

Het kan de moeite lonen om over te stappen naar talen die minder ruimte hebben voor dergelijke obfuscatie.

Ik kan me echt niet voorstellen hoe het volledig herschrijven van software in een andere taal, puur voor deze reden, ooit “de moeite kan lonen”.

[The Zep Man]

Veel software hoeft niet herschreven te worden, want er zijn al implementaties beschikbaar in andere talen. Van xz bestaat een versie in Go, bijvoorbeeld.

Nog steeds voorkomt het overstappen niet dat iemand obfuscated code ergens toevoegt. Dat kan altijd. Wel kan het het makkelijker maken om obfuscated code te vinden, omdat men geen brabbelcode meer verwacht. Als code onleesbaar wordt dan is het daarmee sneller verdacht.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:46]

[Caelorum]

Je kan beter het test framework aanpassen zodat het niet meer mogelijk is. Daar help je veel meer projecten mee. Herschrijven in een andere taal loont gewoon nooit. Een nieuwe implementatie maken in een andere taal zoals bijv. Rust kan uiteraard wel.

[latka]

Testen vind alleen wat je zoekt. Als deze bug alleen triggert als er bepaalde input voorbij komt dan wordt het verdomt lastig. Als je voor de magische 100% line coverage wilt gaan om aan te tonen dat er geen backdoor inzit dan werkt dat ook niet (binaire blob om de zooi in te obfuscaten of op een reguliere regel achter een wel getest statement ofzo).

[Caelorum]

Herschrijven ga je ook alleen maar nieuwe bugs mee introduceren. In dit geval kan je beter je test framework aanpassen dat je geen binary blobs kan includen.
Je bestaande testoplossing beter maken is vaak effectiever dan herschrijven in een andere taal.

[latka]

Herschrijven is nooit een oplossing geweest voor een probleem. Maar staat goed op je cargo cult badge.

[MaestroMaus]

Niet dat het er toe doet; maar wat hebben cargo-cults en het herschrijven van software met elkaar te maken?

[latka]

Regelmatig is het als er een security issues is iemand die roept: herschrijf het in rust/go whatever en het security probleem is opgelost. Op tweakers niet iedere keer, maar vaker dan me lief is.

[RobertMe]

De hoofd ontwikkelaar (/bedenker van het compressie formaat) heeft wel zelf nog een mirror online staan: https://git.tukaani.org/
Daarnaast heeft hij intussen ook een pagina online gezet met zijn reactie: https://tukaani.org/xz-backdoor/ . Inclusief mededeling dat hij komende week verder zal gaan onderzoeken wat er mogelijk mis kan zijn.

Dit sneaky issue dat hij intussen wel al snel heeft "teruggedraaid" is in ieder geval niet echt van zijn hand. Maar is door anderen gevonden en nu door hem gewijzigd. Wat ook min of meer de vraag oproept in hoeverre hij zelf kan valideren wat "echt" is en wat niet. Gezien deze fix is ingegeven door anderen. Waarbij de fix sowieso twijfelachtig is. Want wat in dit stukje van het build proces gebeurd is controleren of een bepaalde sandboxing feature van de Linux kernel beschikbaar is. Origineel werd er alleen gecontroleerd op de aanwezigheid van de `linux/landlock.h` header file. Waarbij de bad actor deze controle heeft herschreven om een stukje C code te compileren en het succes daarvan gebruikt wordt om te bepalen of deze kernel feature aanwezig is. Alleen zit er (intentioneel) een foutje in de C code (die punt dus, dat tot een syntax fout zal leiden) waardoor deze detectie altijd "faalt" en de sandboxing feature dus nooit meer wordt ingeschakeld, ook op systemen dat de feature wel aanwezig is. En de wijziging v.w.b. het detecteren van de aanwezigheid van deze feature is omschreven als zijnde dat het controleren op de aanwezigheid van de header file niet voldoende is en er daarom daadwerkelijk getest moet worden of "het werkt". Wat an zich een legitieme reden zou kunnen zijn om het aan te passen. Alleen wordt er geen "bewijs" geleverd onder welke omstandigheden de vorige "test" mislukt (maar deze wel correct is). Nog los van het feit dat het schijnbaar niet nodig zou hoeven zijn om zelf een stuk code te schrijven en te compileren (de build tools bevatten allemaal hulpmiddelen om dit soort tests te doen waardoor "zelf de C code schrijven" niet vereist is). En dit roept dan ook bij mij de vraag op waarom de hoofd ontwikkelaar nu alleen die . heeft verwijderd, en niet gewoon terug is naar de vorige controle die ook goed zou moeten zijn.

[TD-er]

Ik ben niet thuis in deze bug, dus pure speculatie.
Naar wat ik begrepen heb is hier ondermeer gebruik gemaakt van een methode om een functie-call om te leiden naar een andere call. Wellicht willen ze wel de functie erin houden zodat er verder onderzoek gedaan kan worden om te zien of deze ook echt actief misbruikt wordt danwel of er meerdere routes (libraries/tools) zijn die proberen dit te misbruiken? (of ongewild afhankelijk zijn)

[Reactie gewijzigd door TD-er op 23 juli 2024 08:46]

[MeMoRy]

Wellicht een goede vraag die je hem zelf kan stellen?
Pure speculatie: wellicht valt anders een andere feature die wel goed is om? Of heeft de code toch meerwaarde? Of is dit alleen maar een quick fix.
Hij zal vast nu erg druk hebben en diverse mails ontvangen. Maar wellicht heeft hij toch tijd om jouw vraag beantwoorden

[renecl]

Hoeveel shit is er dan nog over waarvan we het niet weten? , dit is ook per toeval ontdekt

[Reactie gewijzigd door renecl op 23 juli 2024 08:46]

[RobertMe]

Je kunt eigenlijk niet eens spreken over dat dit "per toeval" is ontdekt .

Iemand die benchmarks van PostgreSQL aan het doen was en daarom een zo rustig mogelijk systeem wilde hebben heeft dit gevonden. Omdat er continu kleine CPU spikes waren van sshd (omdat blijkbaar het systeem aan internet hing, en daar dus altijd wel inlogpogingen op plaatsvinden). Na wat trace debugging (waarom is die dat gaan doen?) bleek dit te komen door code uit de liblzma library. Dit heeft hij toen gelinkt aan een PostgreSQL mailing list thread waarbij werd gesproken over dat anderen problemen hadden met liblzma die tot crashes of Valgrind errors leidde. En op basis daarvan is die toen verder gaan zoeken.

Het gaat dus niet om 1 toevalligheid, maar om meerdere toevalligheden waarbij 1 iemand (meermaals?) uit nieuwsgierigheid "down the rabbit hole" is gegaan. En als de exploit in 1x goed was, en niet tot de zeldzame crashes / Valgrind issues leidde was dit mogelijk nooit (/niet binnen een paar maanden) gevonden.

[Maurits van Baerle]

Op Mastodon doet Andres Freund, de ontdekker van het probleem, uit de doeken hoe hij er achter kwam. Het is geen toeval maar er is wel een enorme hoeveelheid specialistische kennis en hele specifieke aandacht voor nodig om het tegen te komen. Het zou mij in ieder geval nooit zijn opgevallen als de SSH daemon net een fractie meer CPU gebruikt dan nodig is.

[RobertMe]

Dat is exact wat ik bedoel. Het zijn meerdere toevalligheden dat hij dit gevonden heeft. Het was voor hem niet nodig om te debuggen waarom sshd zoveel CPU verbruikte. Waarbij die dan wel er achter kwam dat het door liblzma kwam. En de link die die vervolgens weet te leggen met het crash / Valgrind issue van op de PostgreSQL mailinglist is ook nog eens erg toevallig / knap (wat al puur toeval is dat dat probleem in 5.6.0 zat, vervolgens heeft iemand dat issue geconstateerd, gemeld bij PG, en heeft deze persoon dat "toevallig" gelezen).

Wat ik voornamelijk bedoelde is dat het "meer dan toevallig" was. Zeg toeval is een kans van 1 op 1000 dat het gevonden wordt. Terwijl het in deze dan om een kans van 1 op 1000000 gaat, en alsnog gevonden is. Het is een samenspel van een aantal toevalligheden en keuzes die dit uiteindelijk aan het ligt hebben gebracht.

Waarbij dus zoals ik eerder al schreef als de eerste versie (5.6.0) bug/crashvrij was dit niet gevonden was. Dan was dat bericht nooit op die mailinglist gestuurd, en dus niet gelezen. En dan bleef het in deze bij "hoe kan het dat liblzma ogenschijnlijk zoveel CPU cyclussen gebruikt bij een SSH login?". En als deze persoon niet totaal ongerelateerde aan zijn beoogde werkzaamheden was gaan zitten debuggen aan sshd was het ook niet gevonden. (Of in ieder geval niet zo snel gevonden)

[DataGhost]

Heel matige actie van Github. Uiteindelijk is iedereen eromheen aan het werken maar het uitschakelen van de repository heeft nog verdere gevolgen gehad dan alleen het beperken van distributie van de geïnfecteerde tarballs. Beter hadden ze de repository read-only gemaakt en alle tarballs die door Jia Tan ondertekend waren verwijderd. Door het uitschakelen van de hele repository en alle forks ervan:

- Zijn de originele pull requests ook niet meer zichtbaar, waar belangrijke context in zit voor bepaalde wijzigingen.
- Ook was er al een discussie over begonnen binnen het project maar dit gebeurt nu enigszins verspreid op meerdere platforms. Vooral net na het uitschakelen was dat een beetje chaos maar het lijkt dat de discussie nu vooral op deze plek plaatsvindt. NB en hopelijk ten overvloede: iedereen met een account kan daar reageren maar omdat het maar een gist is (en geen discussion) is er geen structuur mogelijk, en de (vele) reacties van bepaalde mensen hebben al aardig wat ruis in het proces gegooid, daarom komen er liefst alleen maar reacties van mensen die daadwerkelijk constructieve en relevante bijdragen kunnen doen.
- De source history is daarmee ook niet meer inzichtelijk, wat het analyseren van de exploit en de tijdlijn heel moeilijk maakt. Op de website van de originele auteur staat een backup van de repository maar de commits van de laatste week/weken zaten daar niet in ter analyse. Er is nog een mirror die wel up-to-date is maar het heeft ook uren gekost voordat die was opgedoken. Ondertussen is ook de backup van de auteur weer up-to-date maar dat kostte dus ook wat moeite.
- Bepaalde distributies konden geen downgrade-package aanbieden simpelweg omdat ook de oude (veilig geachte) releases niet meer toegankelijk waren om een package van te bouwen. Die hebben dus bij andere projecten en mirrors op zoek moeten gaan naar de oude versies.
- Veel software is er wel van afhankelijk en omschrijven naar iets anders is niet altijd wenselijk of (snel) mogelijk. Als straks de hele situatie duidelijk is en er een duidelijk pad is naar herstel, is de originele repository dé plek waar je dat zou neerzetten. Anders loop je de kans dat je straks tig verschillende versplinterde kloon-repositories hebt, al dan niet met de hele commit-geschiedenis voorafgaand aan heel dit gedoe.

Al met al enorm onhandig en onnodig en een actie die het herstelproces eigenlijk alleen maar onnodig frustreert. Ik had verwacht dat ze ondertussen de algehele onvrede erover hadden meegekregen, maar de repository is nog steeds niet beschikbaar.

[Reactie gewijzigd door DataGhost op 23 juli 2024 08:46]

[HollowGamer]

Het probleem is dat GitHub dat allemaal niet kan. Ze kunnen geen repo op read-only zetten en ze kunnen ook geen tags verwijderen. Het zit allemaal in een repo, er is niet echt iets specifieks dat GitHub op die repo doet.

[DataGhost]

Mwah. Alleen de maintainers kunnen committen. Van beide hebben ze de account ook geblokkeerd. Daarmee is het repository al effectief read-only geworden.

Wat betreft de tags, ook al is een deel van de code aanwezig in het repository, is dat niet compleet/voldoende om de backdoor werkend te krijgen. Daarvoor is code nodig die in een handmatig gemaakte en geüploadede tarball zit. Die kunnen ze gewoon verwijderen (of zeer lastig downloadbaar maken) zonder iets anders te hoeven veranderen, aangezien dat niet in het repository zelf zit.

[Reactie gewijzigd door DataGhost op 23 juli 2024 08:46]

[HollowGamer]

Het probleem is dat distro's en andere dus nog altijd die repo kunnen pullen en/of tarballs kunnen downloaden.

Daarom is alles geblokkeerd. Een read-only is leuk, maar het gevaar is dus dat iemand niet op de hoogte is van xz, of juist willen meekijken hoe erop worden gereageerd.

De repo is er, het probleem zijn ook niet alleen die commits/tags. Je zult elk file handmatig moeten langsgaan. Wie zegt dat het enkel deze gebruiker is geweest?

[graceful]

Commits by them such as 18d7facd3802b55c287581405c4d49c98708c136
and ae5c07b22a6b3766b84f409f1b6b5c100469068a show that they were deep
into analyzing the security of xz. They were well placed to insert a buffer
overflow that could allow eg, a targeted xz file to cause arbitrary code
execution. The impact of such a security hole could be much more stealthy and
bad than the known backdoor since it would allow chaining xz with other
unrelated software releases on an ongoing basis.

https://bugs.debian.org/c...8024%22%3E1068024%3C/a%3E

Het gaat zelfs verder dan deze injected code die in dit artikel genoemd wordt. En het probleem is dat simpelweg reverten naar zo’n oude package waar deze changes niet in gedaan zijn, andere packages weer breken.

[cazzie]

Ik gebruik nu Fedora nu een jaartje en ben eigenlijk nog een newbie op linux gebied,
nu vraag ik mij af, is dat XZ niet te vervangen door een ander stukje software ?

[latka]

Xz als compressie format kom ik zelden of nooit tegen, dus wissen/deinstaleren is een goede optie.

[DataGhost]

Dat je het persoonlijk niet tegenkomt wil niet zeggen dat het niet nodig is. Redelijk wat source packages worden tegenwoordig als .tar.xz aangeboden en bijv. ook voor het comprimeren van je kernel/modules/initramfs kan het gebruikt worden omdat het veel beter presteert dan het oude gzip. Ook zorgt dit package voor je lzma-(de)compressor wat vast ook op plekken gebruikt wordt waar je geen weet van hebt. Als het op je systeem geïnstalleerd staat zonder dat je dat zelf hebt gedaan is de kans heel groot dat het een dependency is en dan kan je die niet zomaar wegdoen zonder zaken stuk te maken.

[ernstoud]

Gebruik je embedded devices? Je internet router? Dan zit daar vrijwel zeker een met XZ gecomprimeerde Linux image of rootfs in.

Begrijp je de impact als dit niet ontdekt was? Ik zag een YT video van iemand die zich researcher noemt dat dit een Linux desktop probleem is. Die begrijpt het niet.

[Cybermage]

ruckzichloos deinstalleren niet handig omdat er veel aanhangt. Heb even gechecked met fedora en hingen al meer dan 30 binary's/programma's gelinked eraan.

[downtime]

Vast wel. Maar wat schiet je daarmee op? Er is geen garantie dat andere projecten deze issues niet hebben.

[MneoreJ]

Absoluut. xz implementeert slechts 1 mogelijke methode van compressie en er zijn vele alternatieven. Veel projecten hebben zelfs gewoon configuratie om een van de andere compressiemethodes te gebruiken. Het euvel hier is niet zozeer dat xz absoluut onvervangbaar is (dat is niet zo, en ik stel me voor dat heel wat projecten ondersteuning er nu uit gaan slopen al was het maar uit voorzorg) maar dat het 1) nog maar heel weinig onderhoud had waardoor het project overgenomen kon worden door een Bad Guy en 2) dat het onverwachts opdook als dependency in een kritiek stukje software. Hier zijn ook wel oplossingen voor te bedenken, maar die zijn niet van vandaag op morgen allemaal gedaan.

[RobertMe]

XZ / LZMA is een compressie format dat redelijk wat gebruikt wordt / werd en ook door meerdere "systemen" ondersteund wordt (er zit zelfs een implementatie in de Linux kernel). Overal ondersteuning voor dit format uit verwijderen kan (en er zijn genoeg andere compressie algoritmes) maar zal niet perse eenvoudig zijn (betekend dat heel veel software op zijn minst opnieuw gecompileerd moet worden om geen XZ / LZMA ondersteuning te hebben, als die software daar al de mogelijkheid toe heeft / de ondersteuning daarvoor optioneel is).

Soortgelijke discussies lopen/liepen in ieder geval wel om terug te gaan naar versie 5.2, voordat deze bad actor ging mee ontwikkelen aan xz. En ook dat is niet perse een eenvoudige actie (doordat dus weer veel software gecompileerd is tegen deze nieuwere versie en die daardoor minimaal opnieuw gecompileerd moet worden).

[CR2032]

Nu is het xz, straks is het iets anders. Ook met Linux is het zaak om goed het security nieuws bij te houden.

Voor Fedora zijn nu alleen beta versie 40 en Rawhide geraakt. Heb je de stabiele Fedora 39 of 38 dan is er niets aan de hand want oudere xz versie.

https://fedoramagazine.or...curity-alert-f40-rawhide/

[Jack Flushell]

Het is weer een wilde achtbaan als je leest hoe dit heeft kunnen gebeuren, terwijl zoveel nog niet duidelijk is. Voor geïnteresseerden is de beste samenvatting en uiteenzetting van alles wat bekend is tot nu (wat ik dan heb gevonden): FAQ on the xz-utils backdoor door GitHub gebruiker thesamesam. Zowel de accounts van Lasse Collin (Larhzu) als Jia Tan (JiaT75) zijn op GitHub geblokkeerd, maar Lasse Collin is (waarschijnlijk) niet schuldig, zie bovenstaande link.

Wat ik ook nog tegenkwam is een artikel op Savannah (van GNU) uit 2016 dat uitgebreid beschrijft waarom xz inadequaat is. Staat misschien los van de huidige soap, maar wel heel interessant.

edit: typo.

[Reactie gewijzigd door Jack Flushell op 23 juli 2024 08:46]

[HollowGamer]

Het staat niet in het artikel, maar update z.s.m. je systemen en containers! De meeste zijn terug op een oudere versie (dat kan ook bij updates), al is het nog vaag, aangezien die persoon dus ook commits heeft gedaan destijds.

Beste zou zijn als iedereen zou afstappen van xz/lzma, maar dat gaat vrijwel niet. Ze zijn nu ook kernel commits aan het bekijken, ook omdat hij mogelijk aliassen heeft gebruikt.

Leermoment voor mijzelf, laat je niet pushen en geef niet zomaar je sleutels aan iemand die je niet kent.

[MneoreJ]

Beste zou zijn als iedereen zou afstappen van xz/lzma, maar dat gaat vrijwel niet.

Niet acuut, maar zo heet wordt de soep nu ook weer niet gegeten. Dat iets LZMA compressie heeft is in de meeste systemen geen essentieel ding en uitwisselen met iets anders is goed mogelijk. Dit vergt alleen wel wat beleid natuurlijk, je wil niet van de ene op de andere dag met een hoop gecomprimeerde zut zitten die je ineens niet meer kan decomprimeren. Maar in het uiterste geval (echt kritieke systemen) zou de lzma lib vervangen kunnen worden door een stub die gewoon "sorry, niemand thuis" produceert, nadat je hebt vastgesteld dat je geen LZMA compressie gebruikt/nodig hebt.

[HollowGamer]

Ik ben verre van een expert, maar ik heb gelezen dat LZMA/xz veel gebruikt wordt op de kernel voor modules en ik dacht dat bepaalde package-managers dat formaat gebruiken.

Je kunt overstappen naar alternatieven als zstd, maar dan nog heb je een hele berg gebruikers die niet willen of kunnen upgraden.

[MneoreJ]

Het moet uit de lengte of uit de breedte komen. Je kunt niet en zeggen: "ik kan niet upgraden" en veilig willen zijn voor backdoors in de library. Daar zullen dan harde keuzes gemaakt moeten worden. Wachten in de hoop op een volledige audit van de nu gebruikte xz code die de boel "veilig" verklaart is ook een optie, maar dat kan langer duren dan switchen.

De hoeveelheid gebruikers (eindgebruikers en projecten) die specifiek LZMA nodig hebben op functionele gronden en geen ander compressieformaat willen omdat de alternatieven onaanvaardbaar slechter zijn (te groot, te langzaam, geheugen, whatever) zullen op 1 hand te tellen zijn, als ze er al zijn.

De kernel gebruikt overigens specifiek een embedded versie van xz die (voor zover nu bekend) geen code heeft gehad van de backdoor-bakker, maar ook in de kernel is het absoluut geen vereiste dat xz gebruikt wordt of supported is. Dat is een kwestie van je images anders compressen en dan heeft de kernel het niet nodig.

[Reactie gewijzigd door MneoreJ op 23 juli 2024 08:46]

[HollowGamer]

Ik ben het helemaal met je eens hoor, maar de gemiddelde Linux gebruiker is vrij conservatief.
Debian wordt nu geprezen omdat zij dus niet die upgrades hadden, maar oudere versies zijn mogelijk ook kwetsbaar, omdat die user al 2 jaar bezig was.

Dankzij de rolling is die lek gevonden, anders hadden we het nooit geweten.

Ik weet nu al dat er sysadmins zijn die dan maar xz op een keep-list zetten, omdat ze dan denken dat ze niet kwetsbaar zijn, want het 'werkt nu'. Die denken over het algemeen beter te weten, dan diegene die de distro bouwt en onderhoud.

[devilkin]

Ook waren er bepaalde kernel patches gesubmit waarin de kwaadaardige actor werd toegevoegd als upstream maintainer. Gelukkig zijn die nog niet geaccepteerd.

https://lore.kernel.org/[e-mail]/

[HollowGamer]

Weet je het zeker? Dacht namelijk dat er wel een aantal patches waren geaccepteerd.
Hij of zij heeft kennelijk ook een alias gebruikt, Hans Jansen.

Opensource is mooi, gelukkig kunnen we het terugzien, maar het is wel eng dat ook erg aan social-engineering en trust-abuse (als dat een woord is) is gedaan.

[Immutable]

Is het misschien handig dat mensen die opensource github projecten code comitten volledige KYC doen?
Of iig projecten die aanmerkelijk belang hebben alleen accounts aan mee mogen werken die volledig Doxxed is? Accountability, en online lekker anoniem een beetje belangrijke libs backdoors inbouwen is natuurlijk relatief aantrekkelijk.

Helemaal van die saaie, maar super belangrijke libs met weinig maintainers omdat het zo saai is. Maar zeer aantrekkelijk voor aanvallers.

[veltnet]

Nee, dat is niet handig. Bij de banken werkt KYC ook heel naar.