Link: English autotranslation (Google translate)
Bag overskriftens kryptiske talrække gemmer der sig den sikkerhedsadvisering, der har været genstand for megen omtale, de sidste mange dage. Det viser sig nemlig, at nogen har sneget en bagdør ind i bestemte udgaver af sourcekoden til xz-utils, der findes på mange Unix-varianter (Linux, BSD’erne m.fl.). Bagdøren findes i version 5.6.0 og 5.6.1 - tarball-udgaven, men ikke i selve Git-repository’et (se opslag på Open Wall, link nederst)
Et lumsk angreb
Det er et rigtig nasty supply-chain-attack, fordi det består af to dele. Dels bruges xz i pakkebygningsfasen til at patche funktionsbiblioteket liblzma med ondsindet kode. Men det går skridtet videre… For når liblzma efter patchingen bliver linket sammen med andre softwarepakker, så vil sårbarheden også eksistere i de pakker, der bygges efterfølgende, og som trækker på funktioner fra liblzma.
Ifølge Hackaday, som jeg linker til nedenunder, gik koden som bagdøren udløser specifikt efter at modificere virkningen af funktionen RSA_public_decrypt.
Funktionen RSA_public_decrypt bruges bl.a. til at validere ssh-nøgler, så som Hackaday også nævner, så kunne det for en person med ondsindede intentioner være en mulighed for at gøre OpenSSH’s auth-proces svagere, og dermed nemmere forbigå de normale sikkerhedsprocedurer, når man logger ind på en server via SSH.
Opdaget ved et tilfælde
For open source-miljøet er det en rigtig ærgerlig situation. Først og fremmest godt at det blev opdaget af en årvågen udvikler. Men også en brat opvågning, fordi der måske har været en naivistisk tilgang til kodedeling, ift. til koderevision, ansvarsfordeling og tillid i Open Source-miljøet helt generelt. Særligt med tanke på, hvordan verden udenfor Open Source-miljøet på bedrøvelig vis tager sig ud i disse tider.
Der er endnu ingen, der med 100% sikkerhed ved, om det ondsindede kode er bestilt arbejde af en stat eller en enkelt persons komplot, men uanset hvad resultatet af undersøgelsen bliver, så bør det give det anledning til ændringer i sikkerhedsprocedurene hos de Linux/Unix-distributioner, der hiver pakker ind udefra.
De pakker udgør fundamentet for f.eks en Linux-distribution, som distribueres til millioner af brugere - erhverv og hobbyister - som dagligt bruger Linux på deres computere - servere-, IoT- eller desktopsystemer. Derfor er Linux-distributionernes udgivere også sidste sidste bastion overfor sikkerhedshuller, og bør give pakkerne det sidste tjek inden udgivelse. Det er måske netop nu, at der skal et skævt magisk AI-sovs ind over arbejdsgangene. Det er ikke sikkert, AI kan løse problemet, men det kan udpege problemområder og lette arbejdsbyrden.
Vi kan sagtens blive enige om, at det på papiret er de enkelte upstream-projekter, der selv skal sørge for, at deres kode er testet for sikkerhedshuller og clean. Men det ville forudsætte, at alle er sikkerhedseksperter, og det kan på ingen måde forventes. Det, der mudrer sagen yderligere til her, er jo, at den person der - tilsyneladende - har injiceret malwaren i projektet har været en betroet bidragsyder på xz-projektet i en del år.
Forskellige tilgange til test
Alle projekter har forskellige test-metoder, nogle mere strukturerede og tilbundsgående end andre. Men bottomline er, at pakkerne, der ender ude hos slutbrugerne skal efterprøves bedre. Hvis det betyder, at mængden af nyudviklede funktioner i en distribution bliver færre og at antallet af udgivelser falder, så må det være sådan, det er.
Måske er det på tide at samle kræfterne et formaliseret samarbejde imellem distributionerne, der tester pakker, som kommer ind upstream? De enkelte distributioner kan ikke overkomme den byrde isoleret set. Der er immervæk tusindvls af pakker i f.eks en Linux-distribution, der skal testes, og det - ideelt set - hver gang, der lander en opdatering til en pakke.
Nogle af de community-baserede Linux-distributioners release- og sikkerhedsteams består af få personer, mens det forholder sig anderledes hos de erhvervsrettede. Men selv de har brug for en håndsrækning fra fællesskabet. Om sikkerhedsbristen, der ligger bag CVE-2024-3094 ville blive opdaget nemmere i et sådan samarbejde, må stå hen i det uvisse - men det må alt andet lige give blod på tanden ift. at få skabt bedre systemer, der kan trawle kode igennem for brister - automatiserede såvel som manuelle.
Tornhøj tillid
Min tillid til Open Source-økosystemet er dog ikke svækket - tværtimod. Man kan aldrig undgå sådanne brister, den her var en af de ubehageligt lumske.
Havde det været et operativsystem baseret på proprietær, lukket kode, så kunne sådan en sikkerhedsbrist givetvis få lov at eksistere et stykke tid. Det er og bliver en illusion, at fordi man ikke offentliggør sin kode, så er man bedre sikret. I bedste fald giver det måske arbejdsro.
Det er sket før, at sikkerhedsbrister ikke er blevet patchet tidsnok i closed-source systemer, som Ars Technicas artikel her nævner.
Debatten omkring dette sikkerhedshul afslører også, hvor hårde folk kan være ved hinanden, og vi skal for alt i verden undgå at folk brænder ud. Netop debatkulturen ift. open source og dette sikkerhedsbrud, vil jeg prøve at behandle i et kommende blogindlæg, for det er et studie for sig.
Links
Tråd fra OpenWall
NISTs CVE-beskrivelse med referencer
Hackadays artikel
Low Level Learning: et kig på sagen fra en sikkerhedseksperts perspektiv