Canonical stelt bètarelease van Ubuntu 24.04 week uit wegens malware in XZ

Canonical stelt de release van de bèta van Ubuntu 24.04, ook bekend onder codenaam Noble Numbat, met een week uit. Aanleiding is een ernstige kwetsbaarheid in de veelgebruikte compressietool XZ en de bijbehorende libraries.

Onderzoekers deelden eind vorige week de vondst van een ernstige kwetsbaarheid in de upstream van XZ, een compressietool die in veel verschillende Linux-distributies voorkomt. In versie 5.6.0 en het recentere 5.6.1 van de tool lijkt een backdoor te zitten waarmee aanvallers toegang krijgen tot een systeem. De kwetsbaarheid lijkt een maand geleden te zijn ontstaan.

Ook Ubuntu gebruikt de tool, wat voor maker Canonical nu reden is om alle binary packages die zijn aangemaakt nadat de kwetsbaarheid ontstond te verwijderen en opnieuw te bouwen. "Dat geeft ons de zekerheid dat geen enkele binary in onze builds getroffen kunnen zijn door deze dreiging", schrijft Lukasz 'sil2100' Zemczak van Canonical op Discourse. De beslissing heeft als gevolg dat de bètarelease van Ubuntu 24.04 LTS uitgesteld is tot 11 april. De bètaversie had eigenlijk op 4 april moeten verschijnen.

Canonical is niet de enige die waarschuwt voor XZ. Red Hat raadt specifiek Fedora Rawhide-gebruikers aan om die installaties niet meer te gebruiken. Fedora 40 is niet getroffen, maar Red Hat adviseert desondanks om te downgraden naar een 5.4-build of lager van XZ. Verder waarschuwen openSUSE en Debian voor de fout.

Reacties (30)

[Kodess]

De exploit zorgde er niet voor dat ssh verbindingen over genomen konden worden. Het zorgde ervoor dat je door een poging te doen een ssh verbinding te maken commandos uit kon voeren als root.
Dus de aanvaller stuurt een ssh request met zijn ssh key. Die faalt natuurlijk. Maar ssh zou dan herkennen dat het de aanvaller key was en in die key konden dan commandos worden verstopt.
Untraceable dus.

bron: xzbot project op github (https://github.com/amlweems/xzbot)

[Reactie gewijzigd door Kodess op 23 juli 2024 00:24]

[Armada651]

De verbinding zou daardoor ook niet echt verdacht zijn voor een server met een SSH poort die publiekelijk te bereiken is. Daar worden al geregeld pogingen op gedaan door bots om in te loggen, nog een gefaalde poging zou niet opvallen terwijl daadwerkelijk inloggen als root zou zorgen dat er alarmbellen afgaan.

[CriticalHit_NL]

Vraag me af of zoiets als Fail2Ban die SSH blokkeert na x pogingen enig soelaas biedt, maar dat is natuurlijk op IP-basis en x pogingen.

[Hans1990]

Nee ik denk het niet. Het lijkt er op dat de backdoor checkt of het bericht is versleutelt met een eigen private key. Indien die klopt, doet het nog wat 'deobfuscation'(AES decryptie) en voert het direct een shell commando onder root uit. Als het "goed" is, heeft die maar exact 1 verbinding poging nodig.

Of IP abuse databases zin hebben betwijfel ik. Ik ga er vanuit dat zo'n backdoor niet zal worden ingezet om elke willekeurige wordpress site te hacken. Waarschijnlijk worden dan IPs gebruikt die "schoon" lijken.

SSH van publiek internet afhalen of een IP whitelist instellen kunnen dan veiligere opties zijn, imo.

edit:
spelling/grammatica

[Reactie gewijzigd door Hans1990 op 23 juli 2024 00:24]

[CriticalHit_NL]

Duidelijk, ja in ons geval was onze server sowieso niet vatbaar, maar SSH staat ook niet naar buiten open.
Enkel via VPN verbinding kan de server benaderd worden via SSH.

[bogy]

Mijn boxen hebben SSH server draaien, maar mijn netwerk is zo geconfigged dat je van buitenaf enkel "client" services hebt (ftps/https/...), en dat alles waar ook maar iets van instellingen aan te pas zou kunnen komen je eerst met vpn op het netwerk moet inloggen, want er zijn geen forwards/direct-access poorten bereikbaar voor andere subnetten (ipv6) of netwerken.

Ik heb dat altijd al zo gedaan, dan vermijd ik dat 1 bug in 1 van de vele tools die ik gebruik er toe zou kunnen leiden dat wat maar ook root toegang zou kunnen verkrijgen op 1 of meerdere van mijn boxen. Het is ook de enige reden waarom ik vpn gebruik, security, niet voor obfuscation of omzeilen van DRM/geolocking ...

[Hans1990]

Maar gaat een gefaalde inlogpoging met een SSH key ook niet verdacht zijn? Ik neem aan dat een beetje beveiligde server ook geautomatiseerde infrastructuur heeft om SSH servers te beschermen tegen hackpogingen.

Bijvoorbeeld automatische IP bans bij veelvuldige (gefaalde) pogingen en/of het raadplegen van de vele IP abuse databases. Daarbij zou een SSH key inlogpoging in een veel serieuzere categorie moeten vallen dan de standaard password bruteforces. Dat zou bij uitstek moeten opvallen.

Je hebt er alleen weinig aan, want waarschijnlijk zal de aanvaller maar 1x "gefaald" connecten om daarna een commando uit te voeren die de aanvaller makkelijker toegang verschaft.

[Reactie gewijzigd door Hans1990 op 23 juli 2024 00:24]

[gorgi_19]

Wat ze tot nu toe uit de sourcecode hebben gehaald, zijn het geen gefaalde inlogpogingen bij servers die vatbaar zijn. En aangezien het een geldige library was, die standaard met de releases meeging, was er een redelijke kans dat een poging ging slagen.

Het vermoeden bestaat ook dat, door de werking, de pogingen ook niet eens in de logbestanden zijn terug te vinden.

Vanwege het gebruik van een specifieke public key die nodig was, is ook het vermoeden dat het gerichte aanvallen op specifieke targets mogelijk te maken.

[.oisyn]

Wat ze tot nu toe uit de sourcecode hebben gehaald, zijn het geen gefaalde inlogpogingen bij servers die vatbaar zijn.

De betekenis van "falen" is hier natuurlijk een beetje dubbel. Het gaat om een inlogpoging die faalt; de aanvaller verkrijgt geen actieve SSH sessie. Maar de aanval betreft het uitvoeren van een commando onder root door het sshd proces, en het resultaat wordt onopvallend teruggegeven in het bericht van de falende inlogpoging. De aanval is dan dus succesvol, zonder dat er word ingelogd.

Deze aanval is niet of nauwelijks te onderscheiden van standaard falende inlogpoginen die je altijd wel hebt bij openstaande ssh poorten.

[Reactie gewijzigd door .oisyn op 23 juli 2024 00:24]

[84hannes]

Goede opmerking, ik heb je post naar ons onvriendelijke feedback-forum gekopieerd, zodat de auteur er iets mee kan doen. Als je dat ook omslachtig vind, en nog niet gedaan had, kun je hier een duimpje geven:
https://gathering.tweakers.net/forum/list_message/57772966

[ray0755]

Maakt het dan nog uit als je sshd_config AllowUsers en Match regels bevat? Dus gebruikers die zijn toegestaan, alleen key of password, bepaalde ip-adressen?

[Kodess]

Ik zie die vraag in meerdere maillists voorbij komen, nog niet iemand die het heeft uitgezocht.
De backdoor hijackt de key verificatie. Ik weet niet of AllowUsers en Matchregels daarvoor al worden uitgevoerd.
Ik denk in theorie dat het niet zo is en dat het dus niet helpt. De backdoor gaat voor de verificatie van ssh zelf. Een user match op een key kan pas als de key is geverifieerd.
En ik vermoed dat ze al die checks op 1 plek doen, dus ook de ip check wordt daar pas gedaan.
(dit is allemaal een aanname, heb niet naar de bron van ssh gekeken)

[HollowGamer]

Mocht je wat meer visueel ingesteld zijn: https://youtu.be/vV_WdTBbww4

We moeten de ontdekker toch wel heel erg dankbaar zijn. Het was echt maar minimaal dat de connectie langer duurde. Als de hacker(s) iets beter was geweest, dan was het echt helemaal niet ontdekt (of veel te laat).

Note aan developers en mijzelf: vertrouwen op jezelf en op je tools. Het ging hier mis doordat de hacker deed alsof er iets mis was met de test tooling.

[wimdebok]

Dank voor de uitleg hieronder, dat verheldert. Begrijp dat je met Debian 12.5, waar ik nu op zit, niet kwetsbaar bent voor deze achterdeur. Vind het toch wel heftig, want deze is nu bekend maar wat zit er allemaal in het systeem wat niet bekend is?

Las laatst een artikel over Pyhon libraries met achterdeurtjes erin, zelfde met Javascript libs. Dat is niet goed voor het vertrouwen.

[vanaalten]

Welk OS kan je dan wel vertrouwen? Want ik weet niet zeker of er in Windows mogelijk backdoors zijn ingebouwd voor, bijvoorbeeld, de amerikaanse geheime dienst. Nog los van de mogelijkheid dat er bij Microsoft wellicht werknemers in dienst van andere overheden werken die extra backdoors zouden kunnen inbouwen. En nee, ik wil hier geen Windows-bashing van maken: bij Apple OS is dezelfde mogelijkheid er natuurlijk, al kan ik mij voorstellen dat die vanwege een klein marktaandeel wellicht minder interessant is.

Het enige OS waarbij je er op kan vertrouwen dat er geen backdoors ingebouwd zijn, is denk ik een OS die je zelf van scratch af aan maakt.

[wimdebok]

Klopt! Dat is heel erg de vraag wat je nog kan vertrouwen, iedereen moet wat van iedereen. Of het nou Windows, Android of IOS is. Je weet het niet, en dat is juist de vraag en ellende. Wat te denken van websites volgeramd met code waarvan je amper weet wat het doet. Er lopen hele nare mensen / landen in de rondte.

Wat terzijde, het zou een mooi begin zijn als websites garanties geven over het gebruik van code van derden.

[ATS]

Een OS dat je zelf van scratch af maakt is echter niet zo bruikbaar (en je kan er vanuit gaan dat het ook niet veilig is, niet door backdoors maar door fouten).

[oks]

Inderdaad. Dat je zelf zo veel kennis zou kunnen hebben dat je geen Security fouten zou maken bij de bouw. Het idee Grappig...

[iRobbery]

Je kan natuurlijk niets vertrouwen, ook jezelf niet, dus al code je een OS van scratch zal je er misschien geen bewuste backdoor in coden, maar misschien wel genoeg code voor een exploitable iets.

[gorgi_19]

Het gaat om de XZ library, niet per se debian. Debian levert met de stable releases een oudere versie mee die niet kwetsbaar werd geacht. (In theorie zou je een recente versie van XZ kunnen forceren)

Wat ze tot op heden weten, is (publieke) toegang tot SSH nodig. Als je SSH poort dicht staat, loop je al een stuk minder risico. Er zijn geen 'phonehome' zaken gevonden tot nu toe.

[Reactie gewijzigd door gorgi_19 op 23 juli 2024 00:24]

[Aldy]

Ik vraag mij af als dit closed source was geweest, of ze deze achterdeur zo snel hadden ontdekt en als het toch ontdekt was, toch de release hadden uitgegeven met in hun achterhoofd "Dat patchen we later wel".
Ik heb het nu natuurlijk over commerciële bedrijven met closed source.

Even verbeteringen aangebracht.

[Reactie gewijzigd door Aldy op 23 juli 2024 00:24]

[H1MSELF1SH]

Ook Debian, waarop Ubuntu gebaseerd is, stelt hun release 12.6 uit. Die was gepland voor 6 april. Een nieuwe releasedatum heeft Debian nog niet bekend gemaakt.

[RobertMe]

Debian doet bij "een" versie toch geen version bumps meer? En bookworm gebruikt "maar" 5.4.1 die IIRC sowieso niet kwetsbaar zijn omdat "de backdoor bouwer" toen nog geen contributions gedaan had.

[gorgi_19]

Ook in 5.4.1 heeft hij commits gedaan. Het vermoeden is dat het (nog) niet schadelijk is, maar al zijn commits moeten onder een vergrootglas gelegd worden

https://github.com/xz-mirror/xz/commits/v5.4.1

[Olaf van der Spek]

En bookworm gebruikt "maar" 5.4.1

Het kan ook gaan om (build) infrastructuur van het Debian project zelf. Of computers van Debian developers..

[Auredium]

Verstandig. Het ziet er naar uit dat dit mogelijk het werk is van staatshackers. Je moet er als distro gewoon vanuit gaan dat enige content die in aanraking is geweest met die versie van XZ niet te vertrouwen is. Dat betekend uit voorzorg de boel opnieuw afhandelen en dat kost tijd.

Ik ben blij dat dit gevonden is voor het in de main distro's zat voor langere tijd. Het zou een ramp zijn geweest mocht het succesvol voor langere tijd in alle grote distro's had gezeten. Het toont ook een reeds langer bekend probleem aan; te veel projecten die door een hoop grote namen wordt gebruikt worden e-maintained door te weinig mensen. XZ werd feitelijk heel lang door 1 persoon onderhouden die wat tegen een burn-out zat. Daar is achteraf handig gebruik van gemaakt en dit is niet de eerste keer dat dit een zwakke link blijkt te zijn.

[rbr320]

Dit is inderdaad een gevalletje https://xkcd.com/2347/

[mrjohni]

Voor meer info kijk op: https://arstechnica.com/s...lmost-infected-the-world/

[ejabberd]

Zeer heftig allemaal. Wie hierover een spannende spionagethriller wil schrijven kan ik volgende links aanraden:

https://gist.github.com/t...5a074ebc3dce9ee78baad9e27

https://rheaeve.substack....or-times-damned-times-and

[xilanaz]

Volgens mij had ik zondag een complete rebuild van tumbleweed binnen (2500+ packages), die hadden dat in een dag gefixed, dus waarom stelt men hier een hele release voor uit?

https://lists.opensuse.or...3JJU4RFGHGCVMW2XVLK7SELQ/