Allvarlig sårbarhet upptäckt i XZ Utils

Om det är samma XZ-sårbarhet som pratas om i denna video:

Så gäller sårbarheten när källkoden byggs genom att skadlig kod finns i testfiler som tas med vid byggandet vilket då ändrar dynamic linker's beteende så att den laddar in skadlig kod - vilket öppnar upp för bakdörrar - istället för ämnad ursprunglig källkod - om jag förstått det hela rätt!

Mvh,
WKL.

Ubuntu 20.04 och 22.04 är inte heller påverkade. De kör en äldre version av xz-utils. Oavsett ska man ju inte ha SSH exponerat mot Internet.

Såvitt jag förstått så är han utvecklare i PostgreSQL-projektet och upptäckte det hela när han började gräva i varför det blivit någon form av försämring i PostgreSQL med den nya versionen.

Det står ingenting on PostgreSQL i hans ursprungsmail. Det var en långsam och CPU-intensiv SSH-inloggning som gjorde att han började gräva i det (ssh nämns 24 gånger )

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

Var har du fått din information ifrån? Intressant att veta hur informationen kan bli så förvriden...

Såg notisen om detta häromdagen att man behövde installera uppdateringar på Arch Linux för att fixa detta så jag har gjort det. Var fundersam varför det inte kom någon sådan uppdatering i debian men jag kör stable version på min laptop så det behövs tydligen inte. Men på Arch hade jag en drabbad version så där behövdes det.

Debian har äldre paket, den sårbara versionen finns/fanns bara i Debians test versioner. Arch "verkar" inte påverkas dels pågrund av att dom inte patchar openssh till att länkas mot liblzma, och bakdörren så vitt jag förstår checkar om det är debian/rpm paket som byggs, och används bara då.

Du kan vara ganska lugn.

nja, jag hade gått ner i version ändå. Personen som har lagt in denna backdörr i tarbollen har också varit exklusive maintainer för projektet under 2 år och även lagt in / ändra på kod så just nu är det ingen som vet om det inte finns fler problem som ligger och skvalpar i själva koden. 5.4 är väl sista versionen innan hen var inne och rotade.

Är det här nya Sweclockers grejen tro, att plocka upp en nyhet från forumet och sen slå på trumman i en artikel och skapa en ny tråd? I mitt tycke lite fult att inte länka till ursprungstråden i artikeln.

Wow, snacka om tur att det upptäcktes i grevens tid

Ja, det har jag också stött på flera gånger.

Jag satt och diskuterade detta med bekanta redan kvällen innan men väntade tills nästa dag när det slog mig att kolla om det fanns en tråd om det redan. Tipsade aldrig redaktionen om det eftersom jag var osäker på om det var något man ville skriva om, även om andra tydligen gjorde det.

Stämmer det du skriver om att det inte verkar gå att använda bakdörren på Arch, men de rekommenderar ändå uppdatering utifallatt.
https://archlinux.org/news/the-xz-package-has-been-backdoored...

med den logiken skulle det vara ännu ett argument för att skippa ssh. Så nej. felet ligger i xz.

Hälften av katastrofen i det här kom av att man modifierat en säkerhetskritisk, normalt internetvänd applikation och gjort den beroende av säkerheten i flera andra, egentligen orelaterade projekt, för att den skulle stödja systemd. Det var den klåfingrigheten som förhöjde det till en RCE och det är bäraren av de fingrarna som har ett stort attitydproblem att jobba med.

och man hade kunnat göra det på många andra sätt, t.ex genom PAM. Vad man gjorde var helt sonika att köra ldd mot ssh (målet), kollade vilka olika libs som den länkar mot och började sedan kolla runt på vilken av dessa libs som det fanns utbrända maintainers och man fan libxz.

Att Debian har patchat ssh till att länka mot libsystemd som i sin tur länkar mot libxz är alltså bara den väg som de valde just här, de hade kunnat välja hur många andra vägar som helst. libsystemd har dessutom precis skrivits om till att köra dlopen istället för att länka hårt (den ändringen gjordes innan hålet i xz hittades men har inte släppts än) och då hade detta inte kunnat hända via systemd alls så den vägen är snart helt stängd medan många andra (såsom PAM) är helt öppna så att ta bort systemd från din maskin löser inte ett enda dugg och är inget annat än ett villospår.

Jag kan hålla med. Å andra sidan så påstår vissa att xz ändå i vissa fall skulle få vägar in i OpenSSH via PAM. (Edit: Och då syftade jag inte på inlägget som skrevs samtidigt som mitt, ovan)

Om man inte har läst introduktionen till systemd än, så är det för övrigt intressant teknik, oavsett vad man tycker om härket. Problemet uppkom, om jag förstår saken rätt, eftersom man ville få sshd att starta när en anslutning görs och inte behöva ligga och vänta på den (i stil med hur gamla inetd gjorde). I det läget har man valt en lat implementation där man har dragit in beroenden, i onödan enligt herr Poettering.

En sak som inte diskuteras på så många ställen är användningen av tar-bollar som är manuellt genererade (av skurken i det här fallet), snarare än en viss tagg utcheckad från git eller tarbollar som är reproducerbara från en utcheckning av en tagg. Man använder helt enkelt inte den kod som man kan se i repot, utan något annat. Det är en grej som nog kommer generera en del arbete framöver... Diskussionen jag såg finns här.

Roligt nog är UsePAM också en grej som vissa distributioner valt att aktivera, The default is ''no''

Jag skulle vilja säga att det över lag är ett problem att folk använder något tredjepartsbibiliotek för att slippa skriva tio rader kod. Denna har sedan en drös dependencies, som i sin tur har ytterligare ett halvdussin dependencies vardera o.s.v. o.s.v.. Sen sitter man där med 50+ dependencies som ingen har koll på.

I det här fallet hade Debian en lokal patch som länkar in libsystemd inkl. alla transitiva dependencies till sshd enbart för att skicka en enkel notis att sshd har startat.

Bakdörren har nu blivit reverse engineerad:
https://github.com/amlweems/xzbot