GitHub herstelt repository's van xz, achterdeur is uit tool verwijderd

GitHub heeft de repo's van xz weer beschikbaar gesteld. Het platform haalde die eerder offline nadat er een backdoor in de compressietool bleek te zitten. Na nieuwe commits is die achterdeur verwijderd en is de onbekende Jia Tan als maintainer verwijderd.

De repo's van zowel xz en xz-utils als van xz-embedded en xz-java staan weer online. GitHub haalde de repository's vorige week offline toen bleek dat er malware in de veelgebruikte compressietool xz bleek te zitten. Later werd duidelijk dat het om een bewust geplaatste achterdeur ging.

Een van de twee hoofdontwikkelaars van de repo, Lasse Collin, zegt op zijn eigen website dat de Git-repo's weer via GitHub benaderbaar zijn. Daarmee is het ook voor onderzoekers weer mogelijk om te zien wat er in het verleden aan de repo is aangepast. Collin zegt op zijn website niets over de betrokkenheid van Jia Tan te weten. Jia Tan was de naam van de persoon die de achterdeur in xz stopte en die naast Collin de belangrijkste maintainer van de software was.

Collin zegt dat het e-mailadres en de website alleen nog voor hem toegankelijk zijn. Hij heeft in een commit geschreven dat hij voorlopig de enige maintainer is en dat Jia Tan na de ontdekking van de achterdeur 'plotseling' is verdwenen. Collin heeft daarnaast een commit geplaatst waarin hij bevestigt dat de achterdeur is verwijderd. Hij heeft daarnaast een responsible-disclosurebeleid opgezet waarin hij onderzoekers vraagt om dertig dagen tijd om reparaties door te voeren.

Reacties (30)

[tszcheetah]

Ik moest wel lachen om het commit message:

Backdoors are bad for security.

Naast het weghalen van de backdoor heeft Collin nu ook de eerste code toegevoegd die testbestanden genereert in deze commit. Er is ook wat uitleg bij hoe je dit gebruikt, zodat het geheel controleerbaarder is. Ik ben benieuwd of hij dat voor de rest van de bestanden ook gaat doen.

[Armada651]

Ik vind degene erboven ook goed:

The maintainer who added the backdoor has disappeared.

Zoals gebruikelijk bij open-source is de grootste zorg niet dat er een backdoor is toegevoegd, maar dat er code is toegevoegd zonder de intentie die code te onderhouden.

[roelofz]

Ik vind boeiender of dit een incident is of een topje van de ijsberg.

Heeft GitHub een check of moet open source dit als community borgen?
In het laatste geval kun je als "leek" niet met zekerheid zeggen of iets te gebruiken is of niet.
Denk ook aan de vele forks die opgezet worden om te besmetten met soortgelijke backdoors.

Zorgelijke ontwikkelingen...

[gimbal]

Je richt je alleen op het negatieve. De reactie op het fenomeen vind ik juist een gezonde ontwikkeling. Dit gedoe was immers in een paar uur onder controle, geweldig. En het werd nota bene gespot door iemand die performance testen aan het doen was en het mooiste van alles: die persoon haalde niet de schouders op en dacht "het is het probleem van iemand anders". Hij maakte er zijn probleem van. En anderen namen het serieus!

Ik heb juist weer een stukje vertrouwen in de mensheid teruggewonnen.

[CyBeR]

Je richt je alleen op het negatieve. De reactie op het fenomeen vind ik juist een gezonde ontwikkeling. Dit gedoe was immers in een paar uur onder controle, geweldig. En het werd nota bene gespot door iemand die performance testen aan het doen was en het mooiste van alles: die persoon haalde niet de schouders op en dacht "het is het probleem van iemand anders". Hij maakte er zijn probleem van. En anderen namen het serieus!

Ik heb juist weer een stukje vertrouwen in de mensheid teruggewonnen.

Ja, maar laat wel duidelijk zijn dat we hier feitelijk door het oog van de naald gekropen zijn. De enige reden dat dit ondekt is, is omdat de backdoored code performance-implicaties had, én iemand dat opmerkte, én dat iemand was die competent genoeg was om te achterhalen waar dat vandaan kwam én om te op te merken dat dat niet per ongeluk was.

Als de backdoor "beter" geweest was, dwz die performance-implicaties niet had, hadden we over een paar maanden (want het duurt vaak maanden tot nieuwe versies van software door komen als dat geen security bugfix is) allemaal backdoor'ed sshd's gehad, zonder het door te hebben.

[BCC]

Dus je had liever dat het closed source was? En dat het iemand wel opviel dat er zaken trager werden, maar dat het niet transparant was en er dus niemand achter kon komen dat dit aan de hand was?

Ik ben het helemaal met @gimbal eens, ik vindt dit incident een reden om voor meer opensource te pleiten ipv minder. Waarom vereist de overheid geen opensource software? Wie komt er nu achter als er een backdoor in de gemeentesoftware zit?

[CyBeR]

Dus je had liever dat het closed source was?

Hoe in godesnaam kom je tot die waanzinnige conclusie?

[bzuidgeest]

Hoe in godesnaam kom je tot die waanzinnige conclusie?

Door hoe je comments overkomen. Zoals ze lezen lijk je tegen open source te argumenteren, of op zijn minst te suggereren dat als het closed source was geweest het niet gebeurd was.

Als dat niet je intentie is, tja, dat is het nadeel van comments, de bedoelde intentie is niet altijd de intentie die overkomt.

[Reactie gewijzigd door bzuidgeest op 23 juli 2024 03:59]

[TechSupreme]

Ja dat... of het was juist toeval dat deze serie van gebeurtenissen zo gebeurden waardoor het snel opviel, maar hoe zit het nou met andere projecten dan? Was dt de eerste keer dat ze zoiets probeerden of is het in het verleden wel succesvol geweest en is het nog niet opgevallen?

Ik kan jouw zo een ton aan tools noemen die zonder erbij na te denken "sudo blaat" worden uitgevoerd. Tools die ingeburgerd zijn, tools waar niemand bij nadenkt. Hoe zit het met die tools?

Gezonde ontwikkeling of wake-up call? Bij mij komen toch echt een hoop vragen op.

Ik zou het fijn vinden als alles een keertje van boven naar beneden wordt doorgelicht.

[Reactie gewijzigd door TechSupreme op 23 juli 2024 03:59]

[Mellow Jack]

Dit is geen ontwikkeling. Dit is de realiteit die dr altijd al is geweest. Veel software is geen alles omvattend geheel. Vaak worden externe bibliotheken gebruikt. sommige boeken in die bibliotheek hebben veel auteurs, lezers, reviewers enz. Sommige boeken hebben maar 1 auteur, geen directe lezers en geen reviewers. Sommige boeken hadden veel auteurs maar iedereen is ondertussen iets anders aan het doen. En zo komt elke situatie die je kan verzinnen voor.

Wat ik nog leuker vind zijn de grote partijen die een boek zelf onderhouden. Zo kan het voorkomen dat je versie 3 hebt geïnstalleerd terwijl alle belangrijke security patches uit versie 4 zijn verwerkt. Super handig voor tools die op kwetsbaarheden scannen. Krijg je telkens de opmerking dat je versie 3 gebruikt en moet je gaan bewijzen dat Redhat oid wel security patches xyz hebben gebackport

Edit: volgens mij scanned Github tegenwoordig alle repos waardoor simpele zaken eruit gepikt kunnen worden maar een backdoor ga je niet zo 123 vinden. Wat is het verschil tussen een backdoor en een interface?

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 03:59]

[wica]

Dit is niet de eerste incident en ook niet de laatste.
En nee, GitHub moet die controle niet doen.

Het is aan de partijen, die afhankelijk van opensource zijn en daarmee hun geld verdienen. Om dit op te pakken en op te lossen voor de hele community.

Dit. gezegd hebbende, ben ik ondertussen wel van mening. Als project met een enkele ontwikkelaar. Zo belangrijk is, dat de OpenSource community een mechanisme moet bedenken, om deze ontwikkelaars te ondersteunen. En voor ondersteuning in support, is denk ik van belang.

Ontwikkelen is leuk, maar die support vragen kosten heel veel van een ontwikkelaar. En helemaal, als ze direct bij de ontwikkelaar terecht komen. Een mechanisme, voor eerste lijns support ofzo zou denk ik wel wenselijk zijn.

[SMillerNL]

> Dit. gezegd hebbende, ben ik ondertussen wel van mening. Als project met een enkele ontwikkelaar. Zo belangrijk is, dat de OpenSource community een mechanisme moet bedenken, om deze ontwikkelaars te ondersteunen. En voor ondersteuning in support, is denk ik van belang.

Wat is de OpenSource community? Want voor zover ik weet bestaat er niet een community daarvoor. Ik beheer wat projecten, maakt me dat verantwoordelijk voor alle andere open source projecten?

> Ontwikkelen is leuk, maar die support vragen kosten heel veel van een ontwikkelaar. En helemaal, als ze direct bij de ontwikkelaar terecht komen. Een mechanisme, voor eerste lijns support ofzo zou denk ik wel wenselijk zijn.

RedHat biedt dit als dienst aan, maar volgens mij is het grootste deel van de gebruikers van open source projecten daar geen klant van. Waarom zou je betalen als er een publieke bugtracker is

[latka]

Ach, supply chain attacks zijn er niet alleen in open source. Eigenlijk kun je stellen dat geen enkele software pakket gegarandeerd 100% backdoor vrij is.

[demonite]

Wat @Mellow Jack hierboven ook al meldde, dit is altijd al zo geweest.

En niet alleen bij open source.

Alle software maakt gebruik van 3rd party componenten. Sommige zijn closed source en dan moet je er maar op vertrouwen dat de leverancier zijn zaakjes goed op orde heeft. Bij open source net zo, maar dan kun je iig zelf nog kijken wat je binnen hengelt. Maar eerlijk, wie doet dat nou?

Overigens is het bij open source niet zo dat jan en alleman maar ongezien meuk kan toevoegen. Elke bijdrage wordt (als het project goed opgezet is) wel gereviewed door minimaal 1 van de andere contributors/maintainers.

Wel is het zo dat open source software projecten, waarbij het gebruikelijk is dat de ontwikkelaars elkaar niet kennen en maar sporadisch aan het project werken, zijn wel gemakkelijker voor malafide personen/groepen om te infiltreren dan commerciele software waar alleen werknemers van een bedrijf aan ontwikkelen.

Echter, aangezien "hacken" tegenwoordig een verdienmodel is voor de georganiseerde misdaad en er ook vanuit overheiden meer aan "cyber warfare" gedaan wordt denk ik wel dat je zou kunnen stellen dat de druk op de open source software community aan het toenemen is.

Zover ik weet zijn er nog geen nieuwe ideeen of initiatieven opgezet om dit tegen te gaan. Ik zou ook niet weten hoe.

Hackgroepen zouden tientallen accounts aan kunnen maken en jarenlang her en der zinnige bijdragen kunnen doen tot het moment komt om toe te slaan. Hopelijk wordt dat dan opgemerkt, zoals hier nu gebeurd is.
Het lijkt me niet ontdenkbaar dat zo'n groep met meerdere accounts een open source project joined en vervolgens dmv ruzies bv de originele developers proberen weg te pesten om zo het hele project over te nemen. De kans is niet heel groot, want zodra iets ontdekt wordt is alles natuurlijk in te zien.

Zolang er genoeg eerlijke mensen blijven opletten gaat het goed, maar er zijn geen garanties.

[willemb2]

Deze Jia Tan maakt behalve in xz ook commits in andere projecten (2021 - 2023).

Edit: ik zie nu dat er al iemand op gesprongen is. Ben zelf geen ontwikkelaar en niet goed thuis in de Github workflow, maar neem aan dat het nu wel flink de aandacht heeft.

[Reactie gewijzigd door willemb2 op 23 juli 2024 03:59]

[CyBeR]

Klopt, maar er is IMO geen reden om aan te nemen dat al zijn commits ooit malicious zijn (itt wat sommigen lijken te insinueren).

Hij heeft zover ik kan zien de afgelopen twee jaar gewoon goed werk gedaan bij xz (en wat andere projecten) om vertrouwen te kweken en over tijd steeds meer toegang te krijgen. Om die toegang vervolgens te gebruiken om die backdoor te implementeren. En binnen een week betrapt te worden.

Wel goed om zijn contributies onder een vergrootglas te leggen natuurlijk, en het mooie aan revisiesystemen zoals git is dat je precies kan zien wie, wat, wanneer veranderd heeft dus dat is betrekkelijk simpel om te doen.

Maar dat toont ook wel een beetje een probleem in het systeem: je vertrouwt iemand op basis van het afgeleverde werk, maar dat zegt helemaal niks over je intenties voor de toekomst. Als Jia Tan vanaf het begin vreemde blobs aan het committen geweest was, had dit hele verhaal anders gelopen.

Overigens, ik zeg "hij" omdat ik er van uit ga dat 't één persoon was, maar dat is natuurlijk niet zeker. Het kan ook een groep mensen zijn, of een hele organisatie. Wel is het zo dat hij (of ze) in perfect Engels communiceert in een redelijk consistente stijl waardoor ik iig niet het idee krijg dat er meerdere mensen achter het roer zitten, of iig niet direct.

[Reactie gewijzigd door CyBeR op 23 juli 2024 03:59]

[nzall]

Minstens één van de commits die Jia Tan heeft gedaan in andere projecten was algemeen gezien als onveilig. Dus er is een goede kans dat de andere commits ook problemen introduceren.

[CyBeR]

Die heb ik ook gezien ja. Was misschien een voelsprietje?

[Soldaatje]

In de repo staat dat er inderdaad een team achter hem zat:

Special author: Jia Tan was a co-maintainer in 2022-2024. He and
the team behind him inserted a backdoor (CVE-2024-3094) into
XZ Utils 5.6.0 and 5.6.1 releases. He suddenly disappeared when
this was discovered.

https://github.com/tukaani-project/xz/blob/master/AUTHORS

[rob12424]

Wat ik begrepen heb is dat ze hem eerst overladen hebben met code en overspannen gemaakt hadden en zo gepushed hadden dat die ander co-author werd.

Dat lijkt mij dus echt een team. Je kan niet als iemand zijnde iemand zo overladen en tegelijk zeggen ik ga je wel helpen, maak mij co-author. Dat zou een beetje te makkelijk zijn.

[downtime]

Wat ik begrepen heb is dat ze hem eerst overladen hebben met code en overspannen gemaakt hadden en zo gepushed hadden dat die ander co-author werd.

Dat lijkt me een gevalletje "1+1=3". Volgens de berichten die ik heb gehoord had die maintainer al last van "mental health issues" (nergens is met zoveel woorden gezegd dat hij overspannen was) toen hij voor het eerst contact met die mensen kreeg.
De aanvallers maakten gebruik van die "mental health issues" door erop aan te dringen dat ie hulp accepteerde in het onderhouden van het project omdat er veel achterstallig werk lag waar de maintainer zelf niet aan toe kwam. En in dezelfde periode bood die Jia Tan zijn hulp aan. Maar nergens heb ik gelezen dat zijn "mental health issues" veroorzaakt werden door die aanvallers.

[Renssanting]

Kan ook gewoon een beetje stat-padding zijn, zodat het niet een vers account was dat nooit aan iets anders gecontribute had voordat het plan om de backdoor in xz te krijgen in werking gezet was.

[Cobalt]

Het mag dan wel zijn weggehaald uit de sourcecode. Maar is de versie ook verwijderd van alle repositories?

[demonite]

Vast niet "alle" want met Git maak je een kloon van een repository en de eigenaar van de originele repository heeft uiteraard geen toegang tot die kloons.

Maar dat maakt ook niet uit, want de volgende release van deze software komt niet uit 1 van deze gekloonde repositories maar wordt door xz zelf gedaan.

[CyBeR]

Het mag dan wel zijn weggehaald uit de sourcecode. Maar is de versie ook verwijderd van alle repositories?

Nee, zo werkt git niet. Je kunt de "foute" versies dus nog gewoon terugvinden in de historie van de repo.

Bijvoorbeeld: https://github.com/tukaan...30d835fce46289a3ff72a7b89

[Masvic]

Backdoor*

[berchtold]

ja gebruik gewoon 1 term. ik zie ook overal zowel backdoor als achterdeur staan.

[downtime]

Ik zie het probleem niet. Volgens mij wordt schrijvers over het algemeen ontraden om keer op keer hetzelfde woord in een tekst te herhalen. Af en toe een synoniem gebruiken maakt de tekst leesbaarder. Het is geen proces verbaal ofzo.

[R4gnax]

Het wordt alleen bij het gebruik van technische termen en jargon, die niet bij alle lezers inherent in alle vormen bekend zal zijn, vaak juist weer aangeraden om wel consistent te zijn.