Allvarlig sårbarhet upptäckt i XZ Utils

"Detta efter att säkerhetsforskaren Andres Freund upptäckt och rapporterat om problemet, som i praktiken innebär att skadlig kod i mjukvaran gör den till en så kallad bakdörr, utformad för att tillåta obehörig fjärråtkomst."

Han är ingen säkerhetsforskare, han är en Postgres utvecklare. Står tom i brevet han skickade att han inte är det och han ber andra säkerhetsexperter att analysera bakdörren. Han upptäckte bakdörren av misstag när han testade performance.

klart de har, PAM fyller en viktig funktion om du ska göra mer än extremt simpel användarhantering.

Det är väl inget fel på ssh? Ssh använder sig ju inte av xz, sårbarheten bygger ju helt på en implementation mot systemd.

Men det var ju med glimten i ögat med, det är ju logiskt att rikta sårbarheter mot det som flest använder.

logiken i det hela är alltså att ssh var angripet på samma sätt som systemd så varför då peka ut systemd. Att angriparen har valt den här vägen att gå just i det här fallet är bara för att de har valt det, men en massa systemd-hatare såg att systemd fans någonstans i kedjan och började posta om systemd istället för vad som är det egentliga problemet, nämligen xz, att man på github kan ha en tarboll som inte motsvarar vad som är incheckat och att folk blint tankar hem en tarboll vilket gör alla system så extremt sårbara för en supply chain attack av det här slaget, men istället fokuserar man på systemd vilket inte löser någonting öht.

xz används också av ca 500 andra paket i t.ex Debian.

Kopplingen mellan ssh och xz var dessutom i libsystemd och inte systemd i sig, och det enbart i en patchad version hos Debian och Red Hat. Ssh är dessutom patchad på detta vis enbart för att OpenSSH upstream vägrar att ta emot "linux only" patchar vilket gör att patchen har fått extremt mycket mindre översyn än vad den hade fått om den hade gått via upstream (kan nästan garantera att den via upstream hade lagt in de 10 raderna för sd_notify istället för att länka hårt mot libsystemd).

Vidare ironiskt nog så är ju nästa version av debian/ubuntu/redhat som skulle släppas med denna versionen av xz (dvs 5.6 av xz finns enbart i rolling distros och inte ute hos de stora distributionerna än) samtidigt också ha en version av libsystemd där detta inte längre hade gått (eftersom libsystemd numera använder sig av dlopen istället, främst för att spara på minne).

För att ssh i sig inte var angripet eftersom att det inte har xf som dependency?

Något som används över hela världen för remoteåtkomst av servrar eller var det bara ssh som också råkade ha den egenskapen?

Visst, men alla som inte kör systemd är ju fortfarande skyddade vilket var min poäng (som åter igen skrevs med glimten i ögat).

Poettering, är det du?

ssh var synnerligen angripet eftersom det var målet, hade ssh på de större distributionerna inte länkat till libsystemd så hade de helt sonika bara valt en annan väg, tar vi bort libsystemd och de libs som den drar in så har vi kvar dessa för ssh:

	linux-vdso.so.1 (0x00007ffc555ee000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f9266752000)
	libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f9266724000)
	libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f9266712000)
	libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f9266207000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f92661e9000)
	libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f92661af000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f9266183000)
	libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f926612f000)
	libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f9266064000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f926605e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9265e33000)
	libnsl.so.2 => /lib/x86_64-linux-gnu/libnsl.so.2 (0x00007f9265e19000)
	libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f9265e11000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f9265cea000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f9265bac000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f926684e000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f9265b15000)
	libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f9265ae6000)
	libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f9265ad8000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f9265acf000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f9265abb000)
	libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007f9265a8d000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f9265a67000)

Så det är bara se om du kan göra något liknande för någon av dessa eller deras beroenden. Men visst, låt oss hänga upp oss på systemd när det är libxz som är kontaminerat med syfte att komma åt ssh.

Och alla som kör systemd men inte med en patchad ssh är exakt lika skyddade (och jag kör både systemd och en patchad ssh och är också exakt lika skyddad). Och "skyddade" är fortfarande ett frågetecken för vi vet inte vad mer som de har lyckats stoppa in under de 2 år som de haft kontroll över github kontot, kanske om du kör någon av de andra 500 applikationerna att du blir angripen på något annat vis, vem vet.

Och ja, eftersom jag inte håller med dig så måste jag vara Poettering, finns ingen annan förklaring...

... Via systemd

Nä det är väl mest din oförmåga att kunna ta en "höhö"-kommentar med ett "höhö"-svar utan känner att det absolut viktigaste är att poängtera att en attack (via) ssh som explicit kräver att systemd finns på systemet, inte betyder att man kan säga något om systemd eftersom man hade valt en annan väg annars. Okej, men nu gjorde man inte det, och 100% av de som drabbades körde systemd medan 0% av de som inte körde systemd blev drabbade, vilket jag tyckte var skojigt att höhö:a om för att systemd får mycket skit. Ledsen om det upprörde dig.

är inte det minsta upprörd (varför utgår alla från att man måste vara upprörd bara för att man skriver en kommentar...)

"och 100% av de som drabbades körde systemd medan 0% av de som inte körde systemd blev drabbade" - och som sagt med samma logik så 100% av de som drabbades körde ssh medan 0% av de som inte körde ssh blev drabbade.

Problemet som jag reagerar på är just din "vilket jag tyckte var skojigt att höhö:a om för att systemd får mycket skit", dvs har svårt att se humorn i att göra som mobbarna.

Haha, absolut. Och 100% av de som körde ssh utan systemd klarade sig

Vänner som inte vill prata religion, politik eller systemd är inte mycket till vänner.

Snarast understryker väl den här sortens attack nyttan av att undvika en monokultur: Fri och öppen programvara ger oss valfrihet. Undvik där så är möjligt att lägga alla ägg i samma korg, och försök aktivt göra val som förhindrar att det blir omöjligt att undvika det.

Vilken korg är det, dock? systemd? Isåfall så var det väl inte så relevant i detta fallet bakdörren bara fanns på vissa distar som patchat till extragrejer. Det vore något annat i mina ögon om antingen sshd eller xz-utils faktiskt krävde systemd.

Det och att skriva politiskt laddade artiklar för att sedan varna alla i tråden som skriver något rörande politik verkar poppis det senaste.

Systemd i sig är otroligt hjälpsamt för en del områden. Det finns mycket gott att säga om en händelsebaserad hantering av systemet: det sparar en massa manuellt arbete - mer ju mer flexibel miljön behöver vara. En laptop utan systemd (eller motsvarande i andra operativsystem) är nästan jobbig att använda numera, när förväntningen är att det faktiskt är en mobil dator snarare än ett bekvämare sätt att arbeta på samma stationära dator på olika kontorsplatser.

Men det för också med sig komplexitet och beroenden och en brant inlärningskurva när du väl behöver få det att ändra beteende för att bättre passa in med vad du kanske förväntar dig i en server, i vissa avseenden.

Men vad jag menar är att det borde vara en medveten strategi att köra flera olika operativsystem både på servrar och på klienter och att den här incidenten illustrerar det behovet. Självklart är det i ett företag en avvägning: kortsiktig vinstmaximering kräver strömlinjeformning medan mer långsiktig riskminimering torde kräva heterogenitet. Man borde aldrig kunna hamna i en situation där man inte kan lita på någon del av sin maskinpark eller där hela maskinparken blivit utslagen.

Uppdaterad version