Compressietool xz lijkt malware te bevatten, Linux-distro's waarschuwen

De ontwikkelaars van meerdere Linux-distributies waarschuwen voor een ernstige kwetsbaarheid in de veelgebruikte compressietool xz en bijbehorende libraries. In versies 5.6.0 en 5.6.1 lijkt een backdoor te zitten waarmee een aanvaller toegang tot systemen kan krijgen. Onder andere Fedora, Debian en SUSE waarschuwen gebruikers de nieuwste versies van de distro's niet te gebruiken.

Onderzoekers hebben een ernstige kwetsbaarheid ontdekt in de upstream van xz, een compressietool die standaard in veel verschillende Linux-distributies voorkomt. In de tarballs van de tool wordt in versie 5.6.0 en het recentere 5.6.1 een .m4-bestand meegeleverd waarin instructies staan om een automake aan te maken die niet in de originele repo horen te staan. Die instructies worden onder andere gebruikt als de package liblzma wordt aangemaakt. Die package wordt weer door verschillende tools, waaronder sshd, gebruikt en kan daarmee zorgen voor een supplychainaanval. De bug wordt sinds donderdag getrackt als CVE-2024-3094, maar dat is alleen door Red Hat bevestigd.

Red Hat waarschuwt voor de kwetsbaarheid en raadt specifiek Fedora Rawhide-gebruikers aan die installaties per direct niet meer te gebruiken. Fedora 40-installaties zouden niet getroffen zijn door de kwetsbaarheid, maar Red Hat waarschuwt dat gebruikers alsnog beter naar een 5.4-build of lager van xz moeten downgraden. In Rawhide voegt Red Hat een update toe die dat doet.

Ook OpenSUSE waarschuwt voor de bug. De ontdekker van de bug meldt dat in ieder geval ook Debian kwetsbaar is; Andres Freund merkte de bug op toen hij ontdekte dat inloggen via ssh op Debian erg traag was, wat door de extra payload leek te komen. Inmiddels waarschuwt ook Debian voor de bug, al lijken de stabiele distro's zelf niet kwetsbaar.

De kwetsbaarheid lijkt een maand geleden te zijn ontstaan in 5.5.1alpha-0.1 van xz en zou werken tot aan 5.6.1.-1. Inmiddels is de package van xz teruggedraaid naar de upstream van versie 5.4.5, waardoor de bug niet zomaar terechtkomt op systemen die xz of xz-utils bevatten. Debian-, Fedora-, SUSE- en andere Linux-gebruikers kunnen daarom het beste de xz- of xz-utils-package bijwerken zodat de tool wordt teruggedraaid naar de oudere, niet-kwetsbare versie.

Reacties (139)

[The Zep Man]

Even gekeken.

(eigen analyse weggehaald, die van anderen zijn veel beter!)

Zie dit bericht en de bijbehorende discussie op Hacker News voor meer achtergrondinformatie.

Dit is de betreffende code na de-obfuscatie. Met dit bash script kan je testen of een systeem kwetsbaar is. Open het script uiteraard zelf eerst even met een tekstverwerker. Er staan geen spannende dingen in. Als je geen bericht krijgt na het uitvoeren of het bericht "probably not vulnerable", dan is het onwaarschijnlijk dat het systeem waarop het script draait kwetsbaar is.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 14:52]

[RobertMe]

Met dit bash script kan je testen of een systeem kwetsbaar is. Open het script uiteraard zelf eerst even met een tekstverwerker. Er staan geen spannende dingen in. Als je geen bericht krijgt of het bericht "probably not vulnerable", dan is het onwaarschijnlijk dat het systeem waarop het script draait kwetsbaar is.

Voor diegenen die het script niet aandurven: er zijn een aantal voorwaarden, waarvan deze 2 het meest basic zijn en te controleren zijn zonder scripts:
Ten eerste moet je een sshd executable (/ssh daemon) hebben die gebruikt maakt van liblzma (de shared library die xz meelevert). Om dit te controleren kun je ldd gebruiken ("ldd - print shared object dependencies", aldus de manpage). Dit kun je uitvoeren met als argument de pad naar een executable of shared library, waarna alle shared libraries die deze executable/library gebruikt worden weergeven.
Hiervoor moet je echter ook weten waar de sshd executable zich bevind, wat kan met which ("which - shows the full path of (shell) commands." aldus de manpage).
Echter... de tweede voorwaarde is dat de exploit ook naar "hoe" libzma gebruikt wordt kijkt, welke executable op het moment wordt uitgevoerd. Als dit niet /usr/sbin/sshd is doet de exploit niks.

Dus aan de hand van 2 stappen kun je enigzins een indicatie krijgen of (voornamelijk jou distro als die niet Red Hat / Fedora of Debian / Ubuntu / ... based is) je een mogelijk compromised systeem hebt (zeer waarschijnlijk zul je op de genoemde distro's hiermee sowieso uit komen op "is mogelijk compromised"):

1. "which sshd" => als dit niet "/usr/sbin/sshd" zal de exploit niet worden uitgevoerd
2. "ldd <pad naar sshd, zoals door which geoutput>" => als hier niet liblzma tussen staat wordt de shared library met de exploit uberhaupt al niet gebruikt door sshd

Voorbeeld van op Arch Linux:
$ which sshd
/usr/bin/sshd

Hier wijkt het pad dus af (bin vs sbin)

$ ldd $(which sshd)
linux-vdso.so.1 (0x00007fffe86a0000)
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x00007a1a56b12000)
libpam.so.0 => /usr/lib/libpam.so.0 (0x00007a1a56b01000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007a1a56aad000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007a1a569d5000)
libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x00007a1a56400000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007a1a569bb000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007a1a5621e000)
libaudit.so.1 => /usr/lib/libaudit.so.1 (0x00007a1a5698c000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007a1a5695e000)
libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007a1a56958000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007a1a5694a000)
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007a1a56943000)
libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007a1a5620d000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007a1a56c4c000)
libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x00007a1a56939000)

hier zit liblzma ook niet in de output.

Mocht de conclusie zijn dat deze twee commando's wel duiden op dat het systeem mogelijk vatbaar is dan kun je alsnog of het script uitvoeren of zelf de rest van de stappen van het script doorlopen. Daarin zit mij iets teveel "magic" om er uitleg bij te kunnen geven (doet een hexdump van de library en kijkt vervolgens of er een bepaalde (hex) sequence in die dump zit? Maar ik kan de authenticiteit van die hex sequence ook niet bevestigen. Daar kan ook iets "willekeurigs" staan dat altijd de conclusie "probably not vulnerable" geeft)

[Reactie gewijzigd door RobertMe op 22 juli 2024 14:52]

[Xieoxer]

Inmiddels heeft oorspronkelijke ontwikkelaar, die XZ project is gestart zijn website aangepast. Hij geeft aan dat hij aan het onderzoeken is wat er precies is gebeurd en op basis van zijn tekst lijkt het erop dat hij net zo verbaast is als iedereen, waarom zijn mede collega kwaadaardige code heeft toegepast in de code.

Link: https://tukaani.org/xz-backdoor/

[Ultra]

Op een FAQ pagina over de backdoor [ https://gist.github.com/t...5a074ebc3dce9ee78baad9e27 ] wordt verwezen naar https://jmmv.dev/2023/07/ldd-untrusted-binaries.html : "it is still unsafe to run ldd against untrusted binaries. ldd uses the dynamic linker to load the binary and its dependencies into memory, and then relies on the dynamic linker itself to print details to the console. And because of this, this process can be abused in other working-as-intended ways to trigger code injection [...]"
In dit geval gok ik dat het geen kwaad kan, maar goed om te weten .

[Reactie gewijzigd door Ultra op 22 juli 2024 14:52]

[RobertMe]

Dat was mij onbekend.

En nu er steeds meer bekend wordt blijkt ook dat er op andere plekken gesleuteld is om de exploit te "verbergen". Om het gedrag van sshd aan te passen gebruiken ze een of ander "ifunc" mechanisme, dat als ik het goed heb gebruikt kan worden om te "monkey patchen" ("als functie X wordt aangeroepen roep dan niet daadwerkelijk functie X aan maar mijn vervangende functie Y). Echter bestaat er blijkbaar een "oss fuzz" project van Google om fuzzers uit te voeren op open source projecten, om bugs te vinden. Echter "slaat die aan" op het gebruik van "ifunc". Waarbij er ten eerste een (semi?) legitieme use case voor het gebruik van "ifunc" in liblzma is toegevoegd, en vervolgens bij oss fuzz een PR is ingediend om de "ifunc" controle uit te schakelen. Als in, oss fuzz zou deze exploit gevonden moeten hebben (of in ieder geval het gebruik van "ifunc" waarbij vervolgens in de code op GitHub niet te traceren zou zijn geweest waar dat gebruikt werd). En het "legitieme" gebruik van "ifunc" is al in juni/juli geïntroduceerd in liblzma. Dit middels een PR van ene "Hans Jansen", en die naam duikt vervolgens weer op bij ik meen zowel Debian als Fedora om hun te wijzen op deze "geweldige nieuwe 5.6 release" (zonder uit te weiden op wat die geweldig nieuwe features dan zijn). Dus alles wijst er op dat deze "Hans Jansen" ook betrokken is bij het hele verhaal (/een ander pseudoniem is voor dezelfde persoon / groep *).

En die PR bij oss fuzz toont dus ook aan dat er actief is gewerkt om het ontdekken tegen te gaan. Dus theoretisch zou het dan ook kunnen dat ze bv een PR bij ldd hebben gedaan om te verbergen dat executable / library X (sshd in dit geval) gebruik maakt van liblzma.

* Groep, omdat intussen schijnbaar ook ontrafeld is dat van de 750 commits van dit account de legitieme commits allemaal binnen een bepaald tijdsbestek op de dag zijn ("werkuren"), en de commits die te maken hebben met de exploit buiten dat tijdsbestek (/werkuren) zijn gedaan. Waaruit dus het vermoeden bestaat dat het om twee personen of twee teams gaat waarbij de een het legitieme werk doet en de ander bezig is met de exploit.

[goarilla]

Ken je deze al ...

vagrant@bullseye01:~$ cp $(which ls) ls.nobin
vagrant@bullseye01:~$ ./ls.nobin /
bin dev home lib32 libx32 media opt root sbin sys usr var
boot etc lib lib64 lost+found mnt proc run srv tmp vagrant
vagrant@bullseye01:~$ chmod -x ls.nobin
vagrant@bullseye01:~$ ./ls.nobin
-bash: ./ls.nobin: Permission denied
vagrant@bullseye01:~$ /lib64/ld-linux-x86-64.so.2 ./ls.nobin /
bin dev home lib32 libx32 media opt root sbin sys usr var
boot etc lib lib64 lost+found mnt proc run srv tmp vagrant

[Olaf van der Spek]

"which sshd" => als dit niet "/usr/sbin/sshd" zal de exploit niet worden uitgevoerd

Het script werkt dus alleen als je het als root uitvoert?

[RobertMe]

Het script om te controleren of een installatie getroffen is? Neen, het hoeft zeer zeker niet als root uitgevoerd te worden.

[Olaf van der Spek]

Dan zit "/usr/sbin" niet in PATH..

$ which sshd
$ sudo which sshd
/usr/sbin/sshd

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 14:52]

[rbr320]

Omdat /usr/sbin/ niet in het path van een gewone gebruiker zit zal het script inderdaad de sshd binary niet kunnen vinden. Maar je kunt het script aanpassen door which sshd te vervangen met het pad naar sshd op het systeem of het script aanroepen als PATH=/usr/sbin:$PATH ./detect_sh.bin en dan werkt het script gewoon onder een regulier gebruikersaccount.

[Reactie gewijzigd door rbr320 op 22 juli 2024 14:52]

[scsirob]

Het script kijkt eerst of sshd met liblzma gelinked is. Daarna pas of het een vulnerable versie is. Beide condities kunnen eindigen in "probably not vulnerable".

Jammer dat het script voor beide condities dezelfde melding geeft als het niet aangetroffen wordt. Het is meer informatief als er "(not linked)" en "(no vulnerable signature)" achter had gestaan.

[Echnon]

chmod +x detecht_sh.bin
nog doen als je het zo download van de link.

default Ubuntu 23.04 lijkt iig niet kwetsbaar... maar xz is wel 5.6.1

[Reactie gewijzigd door Echnon op 22 juli 2024 14:52]

[gertvdijk]

default Ubuntu 23.04 lijkt iig niet kwetsbaar... maar xz is wel 5.6.1

Nee, die zit niet in Ubuntu 23.04. https://packages.ubuntu.com/lunar/xz-utils

En ook niet in de aanstaande 24.04 release. https://packages.ubuntu.com/noble/xz-utils (op het moment van schrijven 5.4.5-0.3)

Want de vraag om het in Ubuntu te gaan updaten was nog in behandeling. Die request is naar we nu denken gedaan door een sockpuppet account om te pushen dat het in de laatste nieuwe stable (LTS) zou komen.
https://bugs.launchpad.ne...rce/xz-utils/+bug/2059417
5.6.0-0.2 zat in Debian testing, en de 'fixes' in 5.6.1 zijn normaal gesproken wel kansrijk in een beta-stadium, maar het was wel aan de late kant ivm freezes in Ubuntu.

[Echnon]

Nou wat raar dan

➜ ~ xz --version
xz (XZ Utils) 5.6.1
liblzma 5.6.1

[BeerenburgCola]

➜ ~ xz --version

Je beseft nu wel dat je een potentieel met malware infected command 'xz' hebt uitgevoerd om te checken of je een potentieel infected binary hebt op je systeem ???


In dit geval gebeurt er waarschijnlijk niks (moet als root uitgevoerd worden), maar toch ...

[Echnon]

Tja we zullen het zien of het commando op zich echt wat kan met de malware payload of dat het echt afhangt van de interactie met SSH. Het leuke van deze malware is dat die dus ook compleet open source is, dus wat het kan en hoe het werkt zal wel breed uitgemeten gaan worden de komende tijd.

Wat wel vervelend is, is dat ik, en dan zal ik niet de enige zijn, linuxbrew gebruikt omdat Azure wil dat ik voor bepaalde functionaliteit de laatste versie van de azure-cli nodig heb en die heeft dit als dependency binnengetrokken.... Via de dependency on Python nog wel. Dus leuk dat het productie distro's niet treft, maar al die cloud tooling die toegang tot die productie omgevingen regelt moet tegenwoordig zo'n beetje continue op de cutting edge version draaien

[Reactie gewijzigd door Echnon op 22 juli 2024 14:52]

[gertvdijk]

waar komt die binary vandaan dan?

dpkg -S $(which xz)

en dan even die package source bekijken, bijv.:

apt policy xz-utils

Ik neem aan dat je nu je PC opnieuw installeert, want die versie van xz komt niet van Ubuntu.

[Reactie gewijzigd door gertvdijk op 22 juli 2024 14:52]

[Echnon]

ja klopt... blijkt linuxbrew te zijn. Die hebben het intussen gefixed dus 'brew update' heeft m gedowngrade.

[Speleding]

Goed dat je het zegt! Ik zie nu dat homebrew op mijn Mac ook versie 5.6.1 heeft geïnstalleerd. Na een `brew upgrade` is het gelukkig weer weg. Ik heb nog niet gelezen dat de payload ook op een Mac zou werken, maar wel dat nog onduidelijk was wat de payload doet...

[The Zep Man]

Mocht de conclusie zijn dat deze twee commando's wel duiden op dat het systeem mogelijk vatbaar is dan kun je alsnog of het script uitvoeren of zelf de rest van de stappen van het script doorlopen. Daarin zit mij iets teveel "magic" om er uitleg bij te kunnen geven (doet een hexdump van de library en kijkt vervolgens of er een bepaalde (hex) sequence in die dump zit? Maar ik kan de authenticiteit van die hex sequence ook niet bevestigen. Daar kan ook iets "willekeurigs" staan dat altijd de conclusie "probably not vulnerable" geeft)

De hexwaarde waar die naar zoekt is een handtekening van de kwetsbare functie die wordt aangeroepen door sshd. Als die niet gevonden wordt, dan is het onwaarschijnlijk dat het systeem kwetsbaar is. De term "onwaarschijnlijk" wordt gebruikt omdat de onderzoeker niet kan uitsluiten dat er andere variaties van een kwetsbare library zijn.

[RobertMe]

Mijn punt was meer "ik kan niet bewijzen dat die hex sequence ook daadwerkelijk iets aantoont". Het kan zo zijn dat dat script gemaakt is door een pseudoniem van diezelfde persoon of whatever en deze specifieke hex sequence sowieso niet voorkomt in de library en dus altijd zegt "waarschijnlijk niet vatbaar" terwijl je wel de "bekende" vatbare library hebt.
En het exacte commando, hexdump, ken ik ook niet, en niet getraceerd wat het nu precies doet. Maar dat is met een man page redelijk eenvoudig te achterhalen natuurlijk.

[Ghandi]

Ben even aan het zoeken geweest op OSX; xz zit in de brew package manager en ik had toevallig idd de laatste versie.

Op osx is het commando "ldd" iets anders: otool -L $(which sshd) doet 't

De sshd is van OSX zelf en lijkt - zoals ik het lees - niet kwetsbaar

brew upgrade xz doet de upgrade naar een niet kwetsbare (oudere) release.

[johnbetonschaar]

Zoals ik het begrijp uit de analyse van de ontdekker wordt deze malware alleen meegelinkt op linux-amd64 dus op OS X checken is niet nodig.

[BeerenburgCola]

De 'xz' binary zelf heeft deze potentiele malware wel. Echter als 'stand-alone' tool lijkt het erop dat 'xz' niet gevaarlijk is.
Dus "meelinken" gebeurd wel, maar niet met je SSHD binary op macos.

Toch effe snel een brew upgrade gedaan en deze doet idd een downgrade.

[fastedje]

Fedora was juist wel kwetsbaar had ik volgens de CVE begrepen, andere RedHat distros niet.

[arikkert]

alleen de bleeding edge releases van fedora.
In CVE-2024-3094 lees ik :
Current investigation indicates that the packages are only present in Fedora 41 and Fedora Rawhide within the Red Hat community ecosystem.
No versions of Red Hat Enterprise Linux (RHEL) are affected.

[sepulep]

Op tumbleweed resulteert (sudo) which sshd in /sbin/sshd, maar /usr/sbin/sshd bestaat ook gewoon..

sshd is/was echter uitgeschakeld asls service, dus dat is ok?

[BeerenburgCola]

Default staat sshd op OpenSuse uit, je moet het zelf aanzetten.

[CAPSLOCK2000]

Met dit bash script kan e testen of een systeem kwetsbaar is. Open het script uiteraard zelf eerst even met een tekstverwerker. Er staan geen spannende dingen in. Als je geen bericht krijgt na het uitvoeren of het bericht "probably not vulnerable", dan is het onwaarschijnlijk dat het systeem waarop het script draait kwetsbaar is.

Voor wat het waard is : ik heb het script https://www.openwall.com/lists/oss-security/2024/03/29/4/3 gecontroleerd en ik denk dat het veilig is.

[eivissa100]

Waar gaat dit in godsnaam over? Misschien kan iemand dat in een paar woorden in gewoon Nederlands uitleggen? Dan hebben niet-Tweakers, die ook wat willen leren, er iets aan.

[sepulep]

het programma sshd, vrij universeel gebruikt door linux machines om inkomende beveiligde netwerkverbindingen af te handelen, is gehackt door een library, liblzma, te comprimenteren. Deze library wordt gebruikt door systemd, ook vrijwel altijd onderdeel van een linux installatie. De meeste linux machines zouden hiermee dus toegankelijk worden voor de hacker.

[eivissa100]

Bedankt!

[beerse]

De essentie van het bericht is dat er een binary-executable is die het probleem bevat. Met de genoemde commando's zoek je de binary op en open je ze om te zien welke libraries ze gebruikt. Aan die libraries en de gebruikte versies is te zien of daar het probleem in zit of niet.

[emansom]

Dit project moet in quarantaine worden geplaatst, alle commits gemaakt door @JiaT75 en andere projecten waaraan hij code heeft bijgedragen, moeten als backdoors worden beschouwd en dit project moet worden overgenomen door een vertrouwde partij. Als volgende maand een nieuwe release wordt uitgebracht door @JiaT75 en alle distributieverpakkers er gewoon in meegaan alsof er niets is gebeurd: er is niets geleerd van deze supply chain-aanval.

Er is een kans dat hij een force-push zal uitvoeren, waardoor de geschiedenis van deze git-repository wordt beschadigd. Dus zelfs de repository zelf mag niet worden vertrouwd. Haal indien mogelijk back-ups op van echt heel oude machines voordat hij ooit heeft bijgedragen.

Ja, wees maar zo paranoïde. Als je denkt dat dat niet nodig is, begrijp je niet de ernst van wat vandaag aan het licht is gebracht.

[84hannes]

Dit project moet in quarantaine worden geplaatst, alle commits gemaakt door @JiaT75 en andere projecten waaraan hij code heeft bijgedragen, moeten als backdoors worden beschouwd

Het lijkt er op de de door jou genoemde beheerder erg geraffineerd te werk is gegaan. Hij of zij heeft de tijd genomen door deze kwetsbaarheid over meer dan een jaar over meerdere commits te spreiden en heeft contact opgenomen met beheerders van Fedora om de gecompromitteerde versies in een release te krijgen. Ik kan me voorstellen dat deze persoon niet onder een enkele username op GitHub actief is.

[emansom]

Een aannemelijk scenario.

[Echnon]

Je verlangt terug naar de tijden dat er nog key signing parties waren.

[84hannes]

Je verlangt terug naar de tijden dat er nog key signing parties waren.

Of dat mensen die samen software ontwikkelden elkaar ook wel eens in de echte wereld zagen. Zoals ik het begrepen heb heeft deze individu het vertrouwen van de andere ontwikkelaar heeft gewonnen en toen heeft gewacht tot deze voor langere tijd op vakantie was om deze exploit uit te rollen. Ik ken mensen die in mijn gezicht liegen, maar het is toch makkelijker op schrift.

[Verwijderd]

Ik lees hier terug:
https://news.ycombinator.com/item?id=39870098

GitHub has suspended @JiaT75's account.

EDIT: Lasse Collin's account @Larhzu has also been suspended.

EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page.

[RobertMe]

Oude backups zijn niet perse nodig. Doordat een git commit verwijst naar de volledige historie heb je genoeg aan een commit hash. Als je bv de commit hash weet van een release van zeg 3 jaar geleden kun je nu nog steeds controleren of op zijn minst de repository tot dat punt nog authentiek is (lees: er geen commits voor dat moment zijn aangepast door een rebase + force push. Uiteraard kunnen alle commits daarna wel zijn aangepast).

Uiteraard geldt daarbij wel dat je de herkomst van die commit hash moet vertrouwen.

[84hannes]

Doordat een git commit verwijst naar de volledige historie heb je genoeg aan een commit hash.

Met een kleine asterisk dat git hashes met SHA-1 zijn gemaakt en SHA-1 eigenlijk sinds 2011(?) niet meer als veilig wordt gezien. Ik denk niet dat het makkelijk is een malafide commit te maken met dezelfde hash, maar we moeten ons wel realiseren dat het theoretisch mogelijk is.

[BvdW1978]

Theoretisch wel, maar je herkent die direct als garbage en hij zal ook niet zomaar door een build heen komen.

[84hannes]

maar je herkent die direct als garbage en hij zal ook niet zomaar door een build heen komen.

Voor zover ik het begrijp: om een collision te verkrijgen moet je garbage toevoegen. Een persoon zou dat kunnen herkennen, maar als je een extra binary toevoegt dat heeft de build daar geen probleem mee. Dan moet je alleen nog uitleggen waarom je een binary toe moet voegen, maar volgens mij was dat bij deze backdoor ook goedgepraat als zijnde testdata ofzo.

[RobertMe]

maar volgens mij was dat bij deze backdoor ook goedgepraat als zijnde testdata ofzo.

Correct. Het binaire bestand waar alle shit in zit is goed gepraat onder de noemer "voeg test bestanden toe" (voor (unit) tests dus). Alleen is er geen enkele wijziging in de code om deze bestanden ook daadwerkelijk te gebruiken, wat nogal opvallend is (achteraf gezien).

En achteraf gezien zijn er meer van die phishy commit messages met een "lulverhaal" dat "incompleet" is. De eerste versie van dit de backdoor (uit dat "test bestand") werkte niet (bleek bij de v5.6.0 release) en leide tot crashes / Valgrind issues. In de v5.6.1 release zit vervolgens ook een commit die dat "test bestand" update. Dit onder de omschrijving dat het test bestand niet reproduceerbaar gegenereerd was en die het nu had gemaakt met een zelf gekozen seed. Alleen... is dus nergens gedocumenteerd hoe dat bestand dan (willekeurig) gegenereerd is en wat die seed dan is. Wat dus ook dubieus is (achteraf). Als het doel echt de reproduceerbaarheid van het bestand is dan zet je het commando / de commando's er wel bij (in het commit message), of waar nu om geroepen wordt "open source software moet geen binary files bevatten en deze moeten maar door een duidelijk leesbaar script gegenereerd worden" (wat in dit geval dus "niet kan" want het is helemaal geen willekeurige data maar onderdeel van de exploit).

En een ander voorbeeld hiervan is dat Linux schijnbaar relatief recent een feature genaamd "Landlock" heeft gekregen. Hiermee is het als ik het goed begrijp mogelijk voor een library om te zeggen welke bestandsoperaties die zelf en de "ondergelegen" libraries mag uitvoeren. Een beveiligings feature dus. xz maakt hier blijkbaar gebruik van (vast niet toegevoegd door deze persoon/dit account ). Alleen zal dat de exploit in de weg hebben gezeten. Waarna dit account ook weer een "fix" heeft gedaan. Deze feature wordt tijdens het compilen conditioneel ingeschakeld, op basis van of de "linux/landlock.h" header file aanwezig is. Wat heeft deze actor nu gedaan? De controle aangepast, onder de noemer "alleen het controleren op de aanwezigheid van de header is niet voldoende" is de check aangepast naar "controleer of dit stuk C code (dat gebruik maakt van landlock) compileert". Waarbij er "per ongeluk" een "." staat op een (lege) regel code. Oftewel: het compileren van het stuk code mislukt ten alle tijden (omdat de syntax ongeldig is) en xz/liblzma maakt geen gebruik (meer) van deze beveiligingsfeature. En ook in dit geval missen dus de details van het probleem dat wordt opgelost. Er wordt wel geschreven dat de controle op de aanwezigheid van de header niet voldoende is, maar niet waarom dat niet voldoende is / welke concrete fouten er optreden met de "oude" code die met de nieuwe code niet optreden.

[BvdW1978]

Landlock? Is dat zoiets als pledge onder OpenBSD?

Alles staat of valt uiteindelijk met mensenwerk, en de XKCD over een of andere hardwerkende nerd ergens in een kelder in Nebraska is ook hier weer van toepassing. "We" hebben het niet in de hand, en de corporates snappen het ook niet.. Soms lig ik er wel eens wakker van hoe breekbaar onze hele digitale samenleving aan elkaar hangt.

[Kees]

Zo te zien is hij nu door github offline gezet:

This repository has been disabled.

Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service. If you are the owner of the repository, you may reach out to GitHub Support for more information.

Dat geeft ze de tijd om ernaar te kijken inderdaad.

[RoestVrijStaal]

Dit project moet in quarantaine worden geplaatst, alle commits gemaakt door @JiaT75 en andere projecten waaraan hij code heeft bijgedragen, moeten als backdoors worden beschouwd en dit project moet worden overgenomen door een vertrouwde partij.

Ik vraag mij af op dat op den duur gaat werken.
Bij OpenSSL is hetzelfde gedaan door HeartBleed in de vorm van LibreSSL.
Inmiddels is LibreSSL door vele Linux distro's en aanverwante ecosystemen uitgekost.

[SuperDre]

Hoezo terugdraaien? Waarom niet gewoon oplossen en een nieuwere versie uitbrengen? Geeft maar weer aan hoe slecht gecontroleerd wordt wat er aangepast wordt.
Ook vooral nu uitzoeken hoe die 'bug' er in is gekomen en wie daarvoor verantwoordelijk was.

[RobertMe]

Hoezo terugdraaien? Waarom niet gewoon oplossen en een nieuwere versie uitbrengen?

Omdat 1 van de 2 (core) developers verantwoordelijk is hiervoor? Diegene heeft zowel de binary er in gesneaked verpakt als een test (xz) bestand, als de release gedaan waarbij de release artifacts dus kleine kleine afwijkingen heeft met de daadwerkelijke broncode.

Geeft maar weer aan hoe slecht gecontroleerd wordt wat er aangepast wordt.

Zie hierboven. Iemand is uiteindelijk aangemerkt als mede eigenaar, waarschijnlijk/naar ik aanneem omdat hij al meerdere waardevolle wijzigingen had gedaan. Daarnaast is de enige "flag" in de commits dat er test bestanden zijn toegevoegd in een commit zonder dat deze bestanden vanuit (unit) tests worden aangesproken. Verder zullen die binary files waarschijnlijk sowieso nooit gecontroleerd worden. Waarbij ik mij afvraag in hoeverre je aan de inhoud van het bestand uberhaupt kunt zien "wat er in zit". And last but not least. De ene regel code die het geheel aftrapt (tijdens het compilen / builden die test file "uitvoert") zit niet eens in de repository. Die zit alleen in de (handmatig toegevoegde) release artifacts. Dus al zouden alle commits uitgebreid gereviewd zijn, dan nog was er de mogelijkheid dat dit binaire bestand met een "dubbele betekenis" er doorheen zou komen, en de release artifacts zouden per definitie niet gereviewd worden. Je gaat er immers vanuit dat het de broncode is en klaar. Terwijl als je dan een van deze artifacts pakt en die vergelijkt met de automatisch gegenereerde source zip/tarbal op basis van de repo er dus 1 regel verschil in zit (nadat je op de source download een ./autoconfigure gedaan hebt).
Waarbij het nu best kan zijn dat aan de hand hiervan distro's / packagers wel switchen naar een model waarbij ze rechtstreeks vanaf Git of de ongemanipuleerde source zip/tar (door GitHub gegenereerd) gaan werken en/of beiden gaan vergelijken. Terwijl de kans juist relatief klein zal zijn dat dit nog eens voorkomt.

Ook vooral nu uitzoeken hoe die 'bug' er in is gekomen en wie daarvoor verantwoordelijk was.

Echt verantwoordelijk? Mogelijk een state-actor. Dit lijkt een vooropgezet plan te zijn geweest waarbij deze user alleen al maanden bezig is geweest met deze exploit in te bakken (bv in december al een wijziging aan de website dat de door GitHub gegenereerde source downloads niet gebruikt moeten worden, maar mogelijk nog eerder al waarbij er wordt verwezen naar juni/juli 2023).
Nog los van het feit dat deze persoon al 2 jaar "mede eigenaar" is van het project en waarschijnlijk daarvoor ook al bijdragen deed leveren (om niet als total stranger te vragen om "mede eigenaar" te worden).
Dit gaat dus niet om een simpele "drive by" waarbij een "hacker" met 1 PR een exploit in bakt, hier is mogelijk jaren aan planning aan vooraf gegaan. En als partij A gericht bij partij B wilt binnendringen zal men dat waarschijnlijk met een gerichte aanval doen. Terwijl dit juist ern aanval is waarbij, als niet gevonden, over 1? 2? 3? jaar vrijwel alle RPM & Debian based systemen met SSH geïnstalleerd en aan het internet hangen zo over te nemen waren geweest.

[MneoreJ]

Terwijl dit juist ern aanval is waarbij, als niet gevonden, over 1? 2? 3? jaar vrijwel alle RPM & Debian based systemen met SSH geïnstalleerd en aan het internet hangen zo over te nemen waren geweest.

Het is inderdaad bijna niet te geloven hoe klein het oog van de naald is waardoor we gekropen zijn: als de hacker iets competenter geweest was en geen code had geschreven die voor merkbare delays zorgde (en, in een eerdere versie, voor crashes, al was dat blijkbaar voor niemand een trigger om nog eens goed te kijken naar waarom dan) dan had dit zeer wel onopgemerkt kunnen blijven juist omdat het alleen indirect in een bescheiden library voor compressie zit die niet op het pad van de code ligt en waarvan het niet gelijk duidelijk is dat het een dependency is. En in tegenstelling tot payloads die buffer overflows e.d. uitbuiten kan de backdoor specifiek genoeg zijn dat niemand alarm zou kunnen slaan over verdachte payloads richting sshd of crashes door fuzz tests.

In die zin is het bijna een perfect scenario: weer eens een goede reminder over wat er allemaal fout kan gaan en wat er aan de processen schort, maar (waarschijnlijk) zonder dat de exploit daadwerkelijk tot schade geleid heeft.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 14:52]

[batteries4ever]

Zijn we er doorheen gekropen? Of liggen er nog tig soortgelijke zaken? Ik vraag me af hoe de sterk toegenomen Hacks te verklaren zijn. Dit geval laat zien hoe het redelijk onopgemerkt kan plaatsvinden…

[MneoreJ]

Oh, dit is niet de eerste, noch de laatste backdoor. Gegeven hoe dit ontdekt is is de kans dat dit de eerste backdoor van deze soort is belachelijk klein te noemen. De vraag is niet of er al backdoors van deze soort gebouwd zijn, maar waar.

Echter, dit hoef je niet per se te koppelen aan toegenomen hacks. Deze backdoor, en ik denk ook vergelijkbare anderen, zal specfiiek gemaakt worden om alleen gebruikt te kunnen worden door de aanvaller zelf, in tegenstelling tot algemene kwetsbaarheden die wachten op iemand om ze uit te buiten. Je moet dan denken aan gerichte acties in conflicten e.d., niet een bierbrouwer die gegijzeld wordt door een ransomwarebende en andere "onschuldige" zaken.

[batteries4ever]

… behalve dan dat het ernaar uitziet (disclaimer: buikgevoel) dat er steeds meer dat State actors en grote georganiseerde clubs wordt gewerkt en die hebben wel de middelen wat te doen…

[MneoreJ]

Ja, maar dat is ook precies wat ik bedoel: die mensen gaan niet de InBev afpersen voor centjes en andere dingen die juist in het nieuws komen, maar die wachten tot ze kunnen kijken of ze op de computers van het Ministerie van Defensie in kunnen loggen om daar te spioneren of dingen om zeep te helpen. Dat wordt dan doelgericht ingezet op het moment dat het nodig is en komt ook niet snel in het nieuws.

[dcm360]

Het praktisch enige Github-account dat de hele show bij xz draaide is verantwoordelijk voor de geplaatste dubieuze code. Er is niemand die (binnen afzienbare tijd) een nieuwe opgeschoonde release gaat maken, want er is niemand anders van het project die vertrouwd kan worden. De enige oplossing voor de packagers van de distro's is dus om zo snel mogelijk een oude (veilig geachte) versie als update aan te bieden.

[mrmrmr]

Github heeft de xz repositories inmiddels ontoegankelijk gemaakt ('disabled'). Dat heeft voor en nadelen, het is goed omdat deze repositories niet meer betrouwbaar zijn omdat het kwaadaardige account er jaren aan heeft gewerkt. Het is nadelig omdat nu niet makkelijk kan worden gecontroleerd welke source code als onbetrouwbaar/besmet moet worden bezien, wat de wijzigingen waren en of er nog meer kwaadaardige wijzigingen waren en wat misschien nog wel betrouwbaar is.

[Reactie gewijzigd door mrmrmr op 22 juli 2024 14:52]

[ColonelPhantom]

Dat is inderdaad waar de meeste distros voor kiezen als tijdelijke oplossing.

In de tussentijd is de originele auteur van xz, Lasse Collin, van de situatie op de hoogte gebracht, en diegene heeft intussen ook een statement heeft geplaatst.

Ik ga ervan uit dat over een paar weken o.i.d. Lasse een tarball zal releasen voor een 5.6.2 die wel deugt.

[MneoreJ]

Het gaat hier om een backdoor die met kwade opzet in de repo gestopt is. Dat kun je niet "gewoon" oplossen, je moet een nieuwe repo opzetten en zorgvuldig kijken wat (en wie) nog te vertrouwen is van de oude. Wat distro's doen is nieuwe versies van de package uitbrengen waarin gewoon een oude versie van de code zit die in ieder geval deze backdoor niet heeft (maar ook niet per se 100% bewezen veilig is); dat is voor de eindgebruikers in ieder geval genoeg.

[Cambionn]

Naast de genoemde distro's:
Volgens de Manjaro forums heeft Arch het al opgelost door source van de tarball naar de git tag te veranderen. Manjaro gaat dezelfde fix doorvoegen:
https://forum.manjaro.org...ns-a-vulnerability/159028

[Reactie gewijzigd door Cambionn op 22 juli 2024 14:52]

[RobertMe]

Er spelen bij Arch (& afgeleide?) meer dingen.

Zo zou het script alleen getriggerd worden bij Debian & RPM builds, wat bij Arch dus niet het geval is. En nog belangrijker: liblzma wordt niet gebruikt door sshd, eigenlijk uberhaupt niet, maar sommige distro's patchen sshd om gebruik te maken van systemd (libraries) die op hun beurt weer liblzma includen (die vervolgens weer de compromise triggert). En Arch heeft ssh niet gepatcht om dit te doen, dus sshd maakt uberhaupt geen gebruik van liblzma (te controleren met `ldd $(which sshd)`, hier zou liblzma dus niet bij mogen staan (anders is het systeem mogelijk compromised).

Maar ook daar ben ik (Arch) gebruiker niet echt gerust op, en wel om het feit dat het niet een "drive by" aanval is waarbij iemand malicious code in een project heeft weten te knutselen. Maar het feit dat (1 van de 2) team members dit gedaan heeft, over een traject van meerdere commits, en er vervolgens ook nog eens met de release tarballs gemorreld is. Dit zou dus de volledige geschiedenis van alle contributions van deze gebruiker in twijfel moeten trekken.
Waarmee ik niet wilt zeggen dat deze persoon daadwerkelijk schuldig is, want het kan ook een account takeover zijn. Maar zelfs dat zou al dubieus zijn gezien het niet om "even snel 1 commit er in sneaken" gaat. Maar er meerdere commits zijn geweest (eerst de "test" files in de repository opnemen, daarna werkte de exploit in de 5.6.0 release "nog niet goed" (/zorgde voor crashes, wat onderdeel van de reden is dat het uberhaupt gevonden is) waarna er nog meerdere fixes in het builden hebben plaatsgevonden en de "test" files geupdate zijn (incl een volledige omschrijving om het geloofwaardig te laten lijken)), en dit account ook nog eens de releases heeft gedaan incl. daarbij dus de afwijkende release files heeft geupload. Je zou daarbij toch verwachten dat als het een compromised account is dat de daadwerkelijke persoon achter het account dit ooit opmerkt? (bv een git push willen doen en er achter komen dat er nieuwe commits zijn, "op de eigen naam?!")

Edit:
@MneoreJ hieronder, correct which sshd en niet which ldd, foutje bedankt

[Reactie gewijzigd door RobertMe op 22 juli 2024 14:52]

[MneoreJ]

Je bedoelt naar ik aanneem `ldd $(which sshd)`. En nu overigens maar hopen dat al die andere dependencies ook nog een keer goed naar hun beleid kijken om dit soort dingen zoveel mogelijk te voorkomen... En dat distro's extra goed opletten welke dependencies er extra binnengehengeld worden als je gaat patchen -- bij voorkeur geen, maar als je ze toch toevoegt kan dat het noodzakelijke niveau van auditing plotseling onbewust omhoogschroeven.

[Cambionn]

Ik vind het nu even jammer dat ik reacties op mezelf niet kan upvoten, want ik vind je verhaal zeer interessant!

Om eerlijk te zijn is het eerste wat ik heb gedaan kijken welke versie ik draai en wat de impact is op mijn distro (Manjaro dus. Aka ik wou wetten hebben ze er al wat over gezegd/erkent, wat gaan ze doen/raden ze aan, etc.), en toen kwam ik tegen dat Arch het anders oplost (en dat Manjaro dat overneemt) dan de in het artikel genoemde distro's wat ik noemenswaardig vond. Dus ik was nog niet zo ver als jouw verhaal. Maar zoals ik zeg, is het een zeer welkome toevoeging!

[Reactie gewijzigd door Cambionn op 22 juli 2024 14:52]

[NotHere]

Het blijkt dat de persoon die de malware gecommit heeft al meerdere jaren zeer actief werkt aan de xz code.

Dus naast deze snelle rollback moeten ze nu ook gaan uitzoeken of er wellicht al langer malware in zit.

[RobertMe]

En het is ook geen account takeover. Want intussen worden er steeds meer commits gevonden die aan alle kanten rammelen. Alleen de handmatig geuploade release files bevatten het stuk code dat het lek include in de build (een deel zit wel in de repository verpakt in "test" files, of beter gezegd, als ik het goed begrijp zit alles in die test file(s) verpakt. En is er 1 regel nodig tijdens het build proces om alles af te trappen, en deze 1 regel zit alleen in de handmatige files). De automatisch gegenereerde "source" downloads die GitHub erbij zet bevatten dus niet die ene regel. En deze persoon (/dit account) heeft in december al een regel op de website gezet om niet deze source downloads van GitHub te gebruiken: https://github.com/tukaan...a3bf617584da017051R83-R87 Wat in deze dus een rechtstreekse verwijzing is naar "gebruik de download die ik ga 'besmetten'".

Daarnaast heeft deze persoon blijkbaar ook actief contact gehad met een Fedora developer om de crashes die veroorzaakt werden door deze versie(s) (/5.6.0) te verhelpen (in 5.6.1). Rammelt er op de Debian mailing list vanalles v.w.b. dat er door allemaal willekeurige personen wordt gepusht om deze 5.6.1 versie op te nemen omdat de oude versie tot crashes leidt (en de "starter" is weer ene "Hans Jansen" die ook op andere plekken in dit verhaal terug komt gerelateerd aan code aanpassingen die tot dit totaalplaatje hebben geleid).

En last but not least: waar dit probleem gisteren aan het daglicht is verschenen, is 4 dagen terug de "SECURITY.md" nog versimpelt: https://github.com/tukaan...f4f1d324616a0137a5001c14c . Naar een variant van "geef zo weinig mogelijk info", wat weer gedaan kan zijn om te zorgen dat of de "melder" niet zelf te veel er in duikt (en de malicious code boven water haalt) om om het te "rekken" ("werkt niet" => "ik ga het uitzoeken". Vs "werkt niet omdat ...." waarbij er eigenlijk een adequatere response te verwachten is dan een heel vage "ik ga het uitzoeken en weet niet hoe lang het gaat duren want ik heb geen idee waar te beginnen met zoeken").

[P1nGu1n]

Die package wordt weer door verschillende tools, waaronder sshd, gebruikt en kan daarmee zorgen voor een supplychainaanval.

Het bronartikel zegt juist dat sshd géén xz gebruikt:

quote: https://www.openwall.com/lists/oss-security/2024/03/29/4

openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.

[Kees]

Ja, dus indirect en via-via komt het in sshd terecht. En het is juist in sshd opgevallen omdat degene die het ontdekte opmerkte dat zijn ssh login ineens "traag" (lees: halve seconde langer dan normaal) was. Je wil je niet voorstellen hoe lang dit onopgemerkt zou zijn als deze backdoor snel was geweest..

Ik denk dat dit wel een wakeup call gaat worden en dat diverse organisaties en mensen al druk bezig zijn alle binary blobs in github repos te scannen om te zien of er meer repositories zijn waar er code in een "testfile" verstopt zit.

[Reactie gewijzigd door Kees op 22 juli 2024 14:52]

[TheVivaldi]

Die wake-up call moet er in 2010 al geweest zijn, toen irc-serversoftware Unreal besmet was: https://securelist.com/unreal-backdoored-irc-server/29717/

[MneoreJ]

Dat was een veel basaler geval waarbij er een foute binary op de officiële website geslingerd werd. Van de risico's van zulke dingen zijn mensen zich inmiddel wel bewust en er wordt met checksums gewerkt om te voorkomen dat er in de distributieketen iets fout kan gaan.

Deze backdoor is een stuk geniepiger omdat er geen sprake was van een hack van buitenaf, althans geen simpele; hier is bewust kwaadaardige code toegevoegd aan de officiële repo (mogelijk door een account van een committer die gehackt is, dat weten we dan nog niet).

Wat we met z'n allen altijd een beetje hopen (noodgedwongen) is dat repo's van libraries die op veel (of iig belangrijke) plekken gebruikt worden ook aan serieuze auditing onderhevig zijn (op z'n minst het vier-ogen principe), want indien niet los je dat niet even op met een checksummetje.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 14:52]

[RobertMe]

mogelijk door een account van een committer die gehackt is, dat weten we dan nog niet

Weten we niet, maar is niet aannemelijk. Waarschijnlijk loopt dit in totaliteit al sinds juni/juli 2023. En bv in december is er ook al een soort van voorbereidende commit geweest die op de website een waarschuwing zet om niet de automatisch door GitHub gegenereerde source downloads te gebruiken. Want die zijn, zo blijkt nu, "niet vatbaar" voor deze exploit (de zelf geuploade "release" downloads zit 1 extra regel in die dit hele gebeuren aftrapt). Dat is eigenlijk dus al best opvallend als actie. En was dus ook al 2 maanden voor de 5.6.0 release.

Daarnaast heeft deze persoon contact gehad met een van de Fedora developers om de crashes (die de exploit dus veroorzaakte) op te lossen. Dus dat lijkt ook op zijn minst bewust te zijn geweest om de exploit (beter / daadwerkelijk) te laten werken. Alleen zou het kunnen dat die persoon zijn mail is overgenomen en wellicht via die route enerzijds toegang is verkregen tot zijn GitHub account en anderzijds "in zijn naam" heeft kunnen mailen met die Fedora developer.

[WhatsappHack]

En bv in december is er ook al een soort van voorbereidende commit geweest

I.v.m. linkrot, hier eentje van Archive WBM: https://web.archive.org/w...a3bf617584da017051R83-R87

[dipje2]

debian based distro's (en anderen vast ook) patchen sshd om iets met systemd integratie te doen.
Systemd gebruikt liblzma / libxz voor andere doeleinden. Maar zo komt de payload in de systemd en in sshd userspace terecht.

De payload ook erg 'leuk' verstopt in de brocode. Namelijk in binaire vorm in de testdata. In de code staat een M4 macro die niets doet, maar zodra het buildprocess zijn ding doet zorgt de payload dat die macro wel wat doet, en bouw je broncode met de payload actief.

[fenrirs]

Best ernstig dit. Ik hoop dat ze de bron kunnen traceren

[- peter -]

Lijkt van een Chinese commiter te zijn, die al 2 jaar aan t project bijdraagt.

[Kees]

Ik denk dat het veel te vroeg is om op basis van alleen de naam van een commiter met vingers te gaan wijzen.

Als ik een 'russische | amerikaanse | israelische | nederlandse' spion zou zijn dan zou ik niet onder mijn echte naam op het internet werken.

[jaxxil]

Zodra je een partij bent die graag malware verspreid is het idd natuurlijk prima mogelijk dat er credentials gestolen zijn oid.

[tszcheetah]

Credentials jatten hoeft ook niet. Het kan ook zijn dat de persoon in kwestie recent gerekruteerd is juist vanwege zijn positie in het project. Maar goed, het blijft gissen en speculeren op dit moment, ik ben benieuwd of de waarheid ooit boven tafel zal komen.

[Laurens-R]

En dan jat je juist de credentials wellicht van een Chinese bijdrager, want die zal men wellicht ook eerder verdenken.

[TheVivaldi]

Daarom wijst Peter ook niet met de vinger. LIJKT van een Chinese committer te zijn is niet wijzen, maar een observatie.

[Verwijderd]

Peter, Kees, Sascha, tja, wie weet.

[dipje2]

Het is een maintainer die er al langer zit. Dus er zijn nu twee gedachten:
1) Zijn systemen zijn compromised, dus het is iemand die via de credentials van deze persoon een payload in de code heeft gezet
2) Hij/Zij heeft echt na al die jaren besloten het anders te doen.

Wat ik heb gelezen - maar bind mij er niet op vast - is dat na de introductie van de payload, er memory leaks en/of andere bugs aan het licht kwamen door valgrind checks bij redhat. De persoon in kwestie heeft vervolgens met redhat samen gewerkt om de valgrind problemen weg te werken... die dus kwamen door de payload.

Dus er zijn mensen die punt 1 in twijfel trekken, omdat de persoon vervolgens wel - wat langer - heeft gewerkt aan het oplossen van checks en problemen door de payload.

Maar zoals ik al zei, ik heb nog niet verder naar de details gekeken, dus geen idee hoe het echt zit.

[VHware]

De laatste Debian stable (bookworm) is niet kwetsbaar: https://packages.debian.org/bookworm/xz-utils

Die gebruikt een versie 5.4.1

[TheVivaldi]

Weet je dat zeker? Want ik zit op Deepin V23 en die is gebaseerd op Debian Stable (Bookworm), maar xz zegt:

╰─$ xz --version
xz (XZ Utils) 5.4.5
liblzma 5.4.5

[The Zep Man]

Gebaseerd op != hetzelfde.

Mirror van jouw Deepin release, 5.4.5.
Huidige Debian Bookworm package, 5.4.1.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 14:52]

[TheVivaldi]

Nuja, normaliter als iets gebaseerd is op een stabiele of testing Debian-versie, is de pakketversie gelijk. In dit geval hebben ze blijkbaar besloten om af te wijken.

[Ossebol]

In hoeverre heeft dit gevolgen voor cloudinfra als AWS en Google Cloud? En heeft dit ook implicaties voor Android?

[MneoreJ]

In principe moet alles dat op Debian en SUSE gebaseerd is (of nog algemener RPM packages gebruikt) beschouwd worden als kwetsbaar tot het tegendeel bewezen is. Cloud vendors dienen dit na te gaan bij de machines die zij aanbieden. Doorgaans zijn ze nogal rap bij het patchen van dit soort dingen, zeker als iemand het woord "SSH" laat vallen. Er is geen reden om aan te nemen dat distro's die niet gebaseerd zijn op Debian en/of geen RPM gebruiken (directe) problemen hebben omdat die sshd niet gepatched hebben om een dependency te nemen op libsystemd (dat is indirect wat de backdoor mogelijk maakte), maar ook dat moet per distro bevestigd worden.

Voor Android is dit een non-issue; Android draait geen SSH stock. Je kunt custom SSH draaien, maar dat is dan geen sshd en al helemaal niet gebaseerd op een versie met een patch voor systemd.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 14:52]

[dcm360]

In principe moet alles dat op Debian en SUSE gebaseerd is (of nog algemener RPM packages gebruikt) beschouwd worden als kwetsbaar tot het tegendeel bewezen is.

De soep wordt misschien iets minder heet gegeten dan dat. De stable releases (van Debian en SUSE zelf, of dat ook voor alle afgeleiden geldt weet ik niet) zijn niet recent genoeg om de gemodificeerde xz te bevatten. Specifiek de rolling/unstable releases zijn vatbaar, maar waarschijnlijk ook minder gebruikelijk.

[MneoreJ]

Ja, en dat is een geluk bij wat een groot ongeluk had kunnen zijn, maar dat bedoel ik ook met "tot het tegendeel bewezen is". Zeer waarschijnlijk is het gros van de machines die daadwerkelijk code draaien niet kwetsbaar, maar dat is dan ook redelijk snel vast te stellen. Dit is echter serieus genoeg dat je wil beginnen met aannemen dat je in ieder geval moet checken wat je draait, ook al weet je "100% zeker" dat je alleen maar ongewijzigde stable draait.

[Ick]

AWS rapporteert iig. niet kwetsbaar te zijn: https://aws.amazon.com/se...y-bulletins/AWS-2024-002/

[itcouldbeanyone]

Waarom verhogen ze de versie code niet, zodat het met een simpele Apt upgrade commando opgelost kan worden?

[MneoreJ]

Omdat de xz repo zelf compromised is en niet meer te vertrouwen, inclusief iedereen die eraan werkt. Er kan geen nieuwe versie gebouwd worden totdat men dat van boven tot onder doorgelicht heeft inclusief buildproces, en dat kost linksom of rechtsom meer tijd dan een oude versie terugzetten (en zelfs dat is technisch gezien een compromis waarbij je aanneemt dat daar geen andere backdoor in zat, maar je moet wat). Er zal uiteindelijk wel een nieuwe, schone versie met een hoger nummer komen, maar dat duurt langer.

Edit: Debian unstable heeft dit inderdaad opgelost met een "nieuwe" versie: "5.6.1+really5.4.5-1". Dus als het goed is zal een simpele upgrade deze "nieuwe" versie installeren. Dit zeer elegante () compromis laat in ieder geval de deur open voor 5.6.2/5.7.0, als die er ooit nog komt. Merk op dat dit dus gewoon een retagged oude versie is en dat deze oplossing dus afzonderlijk gedaan moet worden voor elke distro; dit is geen nieuwe versie die je van de xz repo kunt krijgen.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 14:52]

[TheVivaldi]

Ze kunnen natuurlijk wel deze specifieke backdoor eruit halen, een nieuwe versie publiceren en later de rest onderzoeken. Vergelijk het met een dijk: als één iemand er een gat in maakt, dan loopt de boel achter de dijk bij hoog water onder. Men gaat dan ook niet eerst de hele dijk aflopen op zoek naar mogelijk meer gaten voordat ze het eerste aangetroffen gat dichten.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 14:52]

[MneoreJ]

Zeker, maar daarvoor moet je de repo forken, terug naar een oude versie, het buildproces opnieuw nagaan om te bevestigen dat je de oude versie aan het bouwen bent met het oude buildproces, versie ophogen, repo locken en iedereen vertellen "dit is de enige, echte, correcte xz repo, negeer die andere". Dit moet je dan met alle distro's afstemmen. En als je daarbij een fout maakt en er zit alsnog een kwetsbaarheid in, al dan niet een andere, ben je alle geloofwaardigheid gelijk weer kwijt en mag je opnieuw beginnen.

Het is vele malen sneller en minder controversieel om te zeggen "roll aub zelf even terug naar deze oude versie", en dat is de eerste response -- dat is het gat dichtslaan. Dat dwingt eenieder ook om te gaan kijken 1) of zij kwetsbaar zijn en 2) wat er eventueel gebeurd kan zijn tijdens het kwetsbaar zijn. Ja, het is iets vervelender voor de mensen die alleen maar weten hoe je een standaard update doet, maar als die mensen gedachteloos een machine met SSH beheren zit er sowieso al iets mis.

Dit hele verhaal hierboven komt echt nog wel, dat is geen kwestie van weken. Maar gelijk even een update eruit slingeren met een "nieuwe" build (hoop je dan) is echt onverantwoord. Dit was geen oepsje maar kwade opzet.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 14:52]