Het lijkt erop dat een aantal unstable distributies is geraakt door deze backdoor. Fedora 40 is op dit moment nog in een beta fase en wordt ook niet als stabiel gezien. Volgens mij hebben we met elkaar heel veel geluk gehad dat iemand dit toevallig is tegengekomen omdat 'het inloggen wat traag aanvoelde' (geparafraseerd).

Als 'traag inloggen' de nieuwe indicatie gaat worden voor de aanwezigheid van een backdoor, dan houdt mijn hart vast als ik na het paasweekend mijn Windows computer moet opstarten...

Op moment heeft de vinder de meeste informatie.,

Ook gelinkt in het artikel https://www.openwall.com/lists/oss-security/2024/03/29/4

"hoe en wat" :


Binnenkort ongetwijfeld een reverse engineer die het verder uitpluist.

(de exploit code is nog te downloaden, maar was wel gestripped van symbols. Met voldoende kennis/ervaring zeker doenbaar .)

Gelukkig niet in officiële builds. Dus geen beta test versies gebruiken. Hoe zit het eigenlijk met xz-utils onder windows? Volgens mij zit het in veel commerciële software omdat het efficiënte compressie betreft.

Potjandriedubbeltjes!!
Zit er een virus in mijn ubuntu-machine. Ga gelijk over naar W11.

Tussen mijn geneuzel door altijd weer blij met zulke berichten ombij de les te blijven. Vanmiddag even door de man page gegaan van xv. Het is dus "xv -V" om de versie te checken. Ik zit veilig.

Weer heel de dag de tijd om zorgeloos moe van mezelf te worden.

Naast het gebruiken van een kwetsbare versie zijn er nog meer voorwaarden voor de backdoor 'actief' wordt. Er wordt onder andere gekeken naar de specifieke locatie van sshd, en op welke manier de software gebouwd wordt. Volgens mij is er op dit manier geen reden om te denken dat Windows systemen geraakt zijn, maar het is ook nog niet tot op de bodem uitgezocht.

Overigens zijn er wel een aantal stabiele besturingssystemen geraakt. De nieuwste versie was in veel gevallen alleen in de testing versies te vinden (Fedora Rawhide, Debian Sid, Alpine Edge), wat overigens ook gewoon officiele builds zijn. De kwetsbare versie zit bijvoorbeeld in OpenSUSE Tumbleweed, wat je als stabiele versie kan zien. Zoals eerder geschreven zijn meer voorwaarden dus ondanks de aanwezigheid van een kwetsbare versie wil dat niet zeggen dat de backdoor ook echt misbruikt kan worden. Dat zal over de komende dagen wel duidelijker worden.

Mijn bron: https://xeiaso.net/notes/2024/xz-vuln/

De kwaadaardige code in XZ circuleert al langer dan een maand.
Zie ook https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/

Manjaro is naar 5.6.1-2

De betreffende co-maintainer had volledige toegang tot alle code en deze persoon is al jaren bij dit project betrokken. De code kan dus al die jaren niet worden vertrouwd. Er waren 2 maintainers.

Teruggaan naar versie xz 5.4.5 is vooralsnog gevaarlijk, want dat gaat niet ver genoeg terug, de vele wijzigingen (750) gedurende meerdere jaren van de aanvaller zitten in de codebase. Nieuwe maintainers van xz en distributie-maintainers zouden alles moeten terugrollen tot de situatie van voor de betrokkenheid van de aanvaller.

Volg de "backdoor"-link in het artikel naar openwall.com, zoek naar het kopje "== Affected Systems ==", en daar staat het antwoord op je vraag.

Hint: hyperlinks in artikelen staan er niet voor niets, gebruik ze als je meer informatie zoekt. En laat je ook niet meteen afschrikken als een tekst nogal technisch overkomt, er staat vaak genoeg naast abracadabra ook genoeg begrijpelijke taal in om meer te weten te komen. In dit geval staat er met zoveel woorden op welke systemen deze backdoor zich richt.

De compressie bibliotheek heet xz. Niet xv.
xv is een al heel oude viewer voor afbeeldingen onder *nix.

Typefout. Het is xz -V om de versie te checken. Wel blijven opletten.

Die repo is op github nu geblokkeerd. https://github.com/tukaani-project/xz
Ik vind eigenlijk dat distrobouwers nog eens goed moeten kijken wat ze allemaal via de officiële repo's ter beschikking stellen.
Redhat stelt dat alle software gereviewd wordt maar deze hebben ze blijkbaar gemist.

Het gaat hier niet om een virus oen maar om een backdoor in xz compressietool

Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.

He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.
bron: https://news.ycombinator.com/item?id=39866275

Deze "just a guy" (Andres Freund) verdient wel een medaille. Hij wilde alleen maar een open source project helpen een performance probleem op te lossen. Heeft er waarschijnlijk wekenlang belangeloos aan gewerkt.
Wat uitleg: https://www.youtube.com/watch?v=jqjtNDtbDNI

De backdoor zat niet in de version controlled code maar in een binary file. Injection van binary files moet verboden worden!

Want W11 heeft geen achterdeurtjes, dat weet je heeel zeker.
Je hebt persoonlijk ook alle binaries gecontroleerd. En van alle software die je daarop draait of gaat draaien?

Hoeveel "virussen" of backdoors heb je al gevonden in W11?
Alles < 1 en je hebt niet goed gekeken.
Begin dan maar opnieuw.

Onzin. De backdoor zit niet in de codebase! maar in een binary testfile van de xz tarball die tijdens het bouwen wordt ge-include. Die saboterende maintainer had trouwens geen jaren maar 2 jaar rechten.

Ik denk dat die Jia Tan niet bestaat maar een state acter is die er 2 jaar over heeft gedaan om het vertrouwen te krijgen als maintainer. Er zijn ook accounts aangemaakt bij andere distro's met een andere naam om het een en ander te pushen.
We zullen het wel nooit horen. Mijn les is ontmoet eerst iemand in real life voordat je vertrouwen geeft. Beschouw die iemand als een oplichter totdat het tegendeel is bewezen, wat al moeilijk genoeg is.

deze voln / exploit zit NIET in RHEL dus ze hebben niets gemist. ze zagen het waarsch om RHEL 10 te bouwen [die nog lang niet uit is] en hebben actie ondernomen. wat wil je nog meer? geen hackers ter aarde? geen bugs in codes? k vraag me af hoeveel troep er in closed-source zit die niet gezien nog besproken mogen worden. iets zecht me dat daar nog meer dan genoeg zit gezien de hoogte en frequenties van de CVEs bij de closed-source mensen...

whooooosh vwb irony

Waarom geef je willens en wetens zulk fout commentaar? Heb je last van tunnelvisie?

Lees de uitleg eerst voordat je iemand beschuldigd. De backdoor zit niet in de codebase. Review heeft dan ook geen zin. De backdoor zit in de geïnjecteerde binary testfile! Wat begrijp je hier niet aan?

Wat begrijp jij niet aan het woord codebase, dat gaat over alle bijbehorende bestanden, inclusief ondersteunende code en de malware. Lees je eerst eens in voordat je woorden gebruikt waarvan je de betekenis niet kent. Lees nog eens wat ik schreef. Je hebt een hautaine houding, en je deed exact wat je nu de ander verwijt, zonder de benodigde kennis. Review heeft geen zin? Dat is nog meer klinklare onzin.

Het is meer een backdoor, geen virus. Maar dat was al gezegd.

Er zullen meer van dit soort backdoors in Linux distros zitten. Ik vermoed minstens een tiental , als het er niet meer zijn.

De OSS community is zeer groot. Allemaal projecten die allerlei inlichtingenfiguren van allerlei landen aantrekken incl westen die dan meehelpen met 'coden' , eenmaal toegang tot de FTP of CVS, kunnen ze submitten wat ze willen.

De truuk is om veel goeie dingen te coden, maar af en toe een glitch te submitten.

Of wat ze ook veel doen, is de sourcecode in tact laten maar de gecompileerde versie van een source-met-backdoor laten komen.

Niemand die het ziet, want als jij een tool van site X neemt, bijv een rpm, die tot in de repo komt, dan ben je 'goed'. Het verspreiden gaat dan verder via Redhat servers of andere officiele , Debian, Fedora etc , ook met BSD systemen

Toen ik nog in intelligence werkte (ander land, no worries, ben niet Nederlands) hingen we altijd met een groepje rond een opensource project. In die tijd kregen bepaalde projecten veel gratis 'hulp'.

Maar die 'hobby coders' werden aan de achterkant stiekem betaald.

Dus ik weet als geen ander dat opensource een wassen neus is , en dat Linux distributies zo lek zijn als een mandje.

Het is zelfs zo dat Windows 10+11 veiliger zijn in de kernel dan de Linux kernel, vooral nadat Microsoft na 8.1 enorm veel werk heeft verricht in de Windows kernel. Ja, het is een product van de US intelligence community dus die komen overal bij, maar je zult er geen buitenlandse exploits in vinden........ BSD en Linux daarintegen.....

Wij konden bijv in Xen en dan via die weg bij alle websites van een bepaalde provider, en dan databases kopieren. Veel kritische infrastructuur is lek, en die bugs of zerodays zijn helemaal niet bekend bij niemand, ook niet bij CERT, of NSA. De NSA is heus niet de enige speler, of de Russen of Chinezen. Er zijn ook andere kleine, heel kleine, globale keyplayers soms met een betere informatiepositie dan een land als Nederland.

Wat ook mee telt, de meeste mensen denken dat opensource de heilige graal is..... ze kunnen niet eens rxvt compilen, laat staan Xorg met alle dependencies compilen. En al kon je het compilen, hoe weet je of al die sourcecode wel zo veilig is?

Hoe weet je of de compiler geen bug heeft?

Hoe weet je of de compiler waarmee jouw compiler is gecompileerd, geen bug heeft?

Hoe weet je of jouw compiler niet bepaalde code doet verbergen, die er al sinds 1970 in zit?

Zomaar twee brainkrakers ;))))))


sir boomgaard
aka /home/embahzboom31/
humble servant of marduks split brain horror network

Code review heeft inderdaad geen zin want er is geen code van de backdoor software alleen een binary zonder symbols.
Daarom is deze malware zo genieperig. De backdoor (testfile) zit in de tarball waar xz uit bestaat en niet in de codebase.
A codebase is the complete body of source code en dus geen object files. Die wil je ook niet in git want die kan je niet diffen!

Je zit er helemaal naast: https://en.wikipedia.org/wiki/Codebase