De XZ-factor: sociale kwetsbaarheden in open source projecten
Expertblogs
Een Microsoft-consultant ontdekte, min of meer per toeval, dat veelgebruikte open source software was voorzien van een backdoor [1]. Hij vond een backdoor in liblzma, onderdeel van de xz-compressietool, een veelgebruikt component binnen het Linux-ecosysteem. Het toeval ontstond doordat de ontdekker een experiment uitvoerde met zijn eigen database tool op een testversie van Linux-distributie Debian Sid. Debian Sid is de ‘unstable’ release van Debian – een zeer recente versie met de nieuwste code, niet bedoeld voor productiesystemen, maar om mee te testen. De ontdekker onderzocht prestatieproblemen op een systeem met de laatste versie van Debian toen het hem opviel dat zijn beheerverbindingen via het SSH protocol langzamer waren dan normaal. Hij stelde uiteindelijk in verder onderzoek vast dat een nieuw stukje software extra checks deed bij het opzetten van een SSH-verbinding. Vervolgens werd duidelijk dat het stukje code met kwaadaardige opzet was toegevoegd, om bij gebruik van een specifieke sleutel SSH toegang te geven op systeem-niveau [2].
De kwaadaardige code was Debian Sid binnengeslopen via een ‘upstream’ code-commit in XZ [1]. Voor het samenstellen (builden) van een Linux-distributie wordt een heleboel software vanuit allerlei open source repositories bij elkaar gezocht. Daarmee werd de in XZ geïntroduceerde code verpakt in de Sid-release van Debian. Ook andere distributies zoals Red Hat [2], OpenSUSE [3], Kali [4], Arch [5] en Ubuntu [6] bleken de code al te hebben verwerkt in hun ‘unstable’ testversies.
Sociale kwetsbaarheden in kleinschalige opensource projecten
In Januari 2021 meldde zich een vrijwilliger, genaamd JiaTan, bij het XZ project [7]. In eerste instantie werden door deze gebruiker contributies gedaan die op het oog niet kwaadaardig waren, maar ook niet heel waardevol. Een aantal andere gebruikers begonnen vervolgens een discussie richting de hoofd-ontwikkelaar van XZ, om de betreffende ‘quality of life’ fixes van JiaTan sneller door te voeren. Later blijkt dat die andere gebruikers waarschijnlijk gelieerd waren aan de aanvals-operatie. JiaTan verdedigde de originele ontwikkelaar van het project en gaf richting de klagers aan dat ze zich niet moesten haasten, mogelijk om zijn vertrouwen te winnen.
Na een aantal maanden van dergelijke interactie werd JiaTan uiteindelijk het vertrouwen gegund door de originele ontwikkelaar. Die ontwikkelaar gaf aan last te hebben van sociale en mentale problemen, en verwelkomde de hulp van JiaTan door hem officieel een auteur-status toe te kennen, zodat hij zelf commits kon uitvoeren van code. Dit hele proces duurde twee jaar en stelde JiaTan uiteindelijk in de gelegenheid om onafhankelijk codewijzigingen in het project uit te voeren. Deze toegang werd zorgvuldig en voorzichtig gebruikt: pas krap een jaar na het verkrijgen van de toegang gebruikte JiaTan deze om daadwerkelijk kwaadaardige code toe te voegen. Wie deze JiaTan was en door welke actor de aanval is opgezet, is (nog) niet bekend.
Het toevoegen van de code gebeurde op een geraffineerde, geobfusceerde manier. De code werd toegevoegd aan onderdelen van de software die alleen worden gezien en gebruikt bij het builden van nieuwe software, niet als onderdeel van de code die daarna gebuild werd. Deze code werd vervolgens hergebruikt in het buildproces van de verschillende genoemde Linux distributies.
Zicht op de kwaliteit en werking van Open Source projecten
De gevonden backdoor benadrukt het belang van waakzaamheid en grondige controle, binnen open source projecten én bij afnemers van open source software. In deze blog bespreken we hulpmiddelen die keten-specialisten kunnen gebruiken om soortgelijke veiligheidsrisico's in andere open source projecten te identificeren. Het doel is om een beeld te vormen van de daarvoor beschikbare meetmiddelen, waarmee dreigingen die verbonden zijn aan open source software kunnen worden geïdentificeerd en beheerst.
Het identificeren en mitigeren van veiligheidsrisico's in open source software vereist een systematische aanpak. Een effectieve manier om de veiligheid van open source projecten te beoordelen en te verbeteren is door gebruik te maken van de metrics, die door de CHAOSS (Community Health Analytics Open Source Software) organisatie zijn ontwikkeld [8]. CHAOSS is een Linux Foundation project dat zich richt op het creëren van analytische en evaluatieve tools om de gezondheid van open source projecten te beoordelen. Hieronder bespreken we enkele relevante CHAOSS-metrics die kunnen helpen bij het identificeren van veiligheidsrisico's zoals de xz-backdoor.
1. Code Review Efficiëntie
De efficiëntie van code reviews is cruciaal om veiligheidskwetsbaarheden vroegtijdig op te sporen. Metrics zoals de Time to First Response en Time to Merge geven inzicht in hoe snel codebeoordelingen plaatsvinden en hoe snel wijzigingen worden geïmplementeerd. Een trage respons kan duiden op onderbezetting of onvoldoende beveiligingsfocus, wat risico's verhoogt.
2. Issue Resolution
De snelheid en efficiëntie waarmee beveiligingsproblemen worden opgelost, is een andere belangrijke indicator. CHAOSS meet dit door middel van de Issue Resolution Time, die helpt te begrijpen hoe actief een project is in het aanpakken van gemelde problemen. Een lange Issue Resolution Time kan wijzen op een gebrek aan middelen of prioriteit bij beveiligingsissues.
3. Community Engagement
Een actieve en betrokken gemeenschap kan significant bijdragen aan een betere beveiliging. Metrics zoals Contributor Growth en Organizational Diversity geven aan hoe divers en groeiend de gemeenschap is. Projecten met een hoge mate van betrokkenheid en diversiteit in bijdragers zijn vaak robuuster, omdat meer individuen vanuit verschillende achtergronden naar de code kijken.
4. Code Quality
Codekwaliteit is direct gekoppeld aan softwareveiligheid. metrics zoals Code Changes, Code Churn, en Code Review Depth geven inzicht in hoe vaak code wordt herzien en hoe grondig deze reviews zijn. Projecten met frequente, grondige code reviews en lage churn rates zijn waarschijnlijk veiliger.
5. Risicomanagement
Ten slotte is het meten van de effectiviteit van risicomanagementpraktijken essentieel. CHAOSS biedt metrics zoals Risk Assessment en Security Response Efficiency die helpen bepalen hoe effectief een project is in het identificeren en reageren op veiligheidsbedreigingen.
CHAOSS Metrics in de praktijk
Vanuit de factsheet Software Supply Chain Security en Open Source [9] bent u mogelijk al bekend met de noodzaak om gedegen kennis te nemen van de kwaliteit en betrouwbaarheid van Open Source softwareprojecten. In de factsheet wordt ervoor gepleit om een scherp beeld te vormen van de toeleveringsketen, voor zowel open source als closed source software. Hiervoor is het ontwikkelen van ketenspecialisme, of het aan- of uitbesteden daarvan, een belangrijke stap. Daarmee kan worden gewerkt aan het inzichtelijk krijgen van de Software Bill of Materials (SBOM), en kan in de keten een verantwoordelijkheid voor elk component worden belegd.
Degenen die binnen de keten verantwoordelijk zijn voor dit inzicht moeten aan de slag om een beeld te krijgen van de kwaliteit en betrouwbaarheid van de betreffende componenten. Om een beeld te vormen van de toepasbaarheid van de CHAOSS Metrics onderzocht het NCSC een selectie van een aantal van de metrics, beperkt tot kenmerken die eenduidig vanuit een openbare bron te zijn herleiden:
- Project is beschikbaar via Github;
- BUS-factor [10]: de BUS-factor is het kleinste aantal personen dat verantwoordelijk is voor minstens 50% van de bijgedragen codewijzigingen. Bijvoorbeeld: factor 1 betekent dat meer dan de helft van het project door één persoon wordt gedragen.
- Elephant-factor [11]: hoe afhankelijk is het project van grote bijdragers/organisaties. Bijvoorbeeld: factor 1 betekent dat meer dan de helft van het project door één organisatie wordt bijgedragen.
- Leeftijd van het project
- Aantal auteurs
- Aantal contributeurs
- Eerste commit-datum
- Laatste commit-datum
In deze verkenning selecteerden we softwarepakketten die deel uit maken van Buildroot, een veelgebruikt systeem voor het bouwen van (voornamelijk embedded) Linux distributies. Buildroot specificeert softwarepakketten die de kern vormen van vele Linux distributies en levert ook directe verwijzingen naar de locatie van broncode op basis waarvan gebouwd wordt. Vervolgens beperkten we deze selectie tot pakketten waarbij de verwijzingen naar de broncode een git repository betreft. Een git repository bevat de volledige ontwikkelgeschiedenis van een project in een gestructureerde vorm genaamd commit logs. De selectie hebben we verder beperkt tot git projecten die op Github beschikbaar zijn, om ook statistieken die Github genereert (buiten het git protocol) te kunnen benutten.
Deze filterstap levert al een forse beperking op wat de zoekruimte beperkte tot 241 pakketten van de in totaal 3115 gebruikte pakketten in de Buildroot Linux distributie.
Op basis van de geselecteerde metrics in dit voorbeeld werd daarna een Python script gebruikt, om de ontwikkelgeschiedenis van deze pakketten bij Github op te vragen en een overzicht te genereren. De resultaten filterden we vervolgens op projecten met:
- Leeftijd ouder dan 12 jaar
- Een BUS-factor kleiner dan 4, en/of een Elephant-factor kleiner dan 4
- Active (laatste commit in maart 2024 of later)
Deze lijst levert, ondanks de filtering en beperkingen op beschikbaarheid van data, een relatief bonte verzameling met componenten op.
Het werpt een licht op beperkingen van de methode, of in ieder geval de noodzaak voor interpretatie. Zo staan de “open-vm-ware-tools” er tussen, omdat dit pakket door één bedrijf (VMWare) als open source wordt aangeboden. De commits voor dit project worden door één Github-account bijgewerkt, maar waarschijnlijk binnen VMWare door een team van ontwikkelaars onderhouden en getest. Dit past bij de verwachting van een VMWare-product, waarvan de bron open is maar het ontwikkelproces niet, Elephant factor 1 heeft.
Toch geeft het overzicht ook een interessante inkijk in veelgebruikte pakketten waarbij meer dan de helft van de ontwikkeling op twee personen van twee organisaties leunt.
Meteen aan de slag met CHAOSS metrics?
Ons experiment laat zien dat het verkrijgen van inzicht in de kwaliteit altijd een sterk verband houdt met subjectieve interpretatie van de gebruikte kenmerken:
- Welke criteria stellen wij op basis van te mitigeren risico’s?
- Vinden wij het afdoende dat er naast 1 á 2 ontwikkelaars ook partijen contractueel aansprakelijk zijn als het een keer mis gaat?
- Is de controle van één persoon over een open source pakket wenselijk en hoe gaan we om met daaruit voortvloeiende risico’s? Zijn er meer deskundige partijen die we daarvoor onder contract hebben staan? En zijn die risico’s daarmee operationeel en juridisch goed afgedekt?
Zoals u leest zijn de maatstaven in de CHAOSS modellen de waarde van een analyse onlosmakelijk verbonden met de risico-inschatting en risk-appetite van de afnemende organisatie. Het is daarom een waardevol instrument wat juist bruikbaar is om realistische scenario’s af te dekken die specifiek op de eigen organisatie van toepassing zijn.
Het actief toepassen en monitoren van de CHAOSS metrics vergt een relatief hoog ICT-volwassenheidsniveau. Immers heeft het toepassen van de metrics voor afnemers alleen zin als er een SBOM beschikbaar is voor de software die moet worden beoordeeld met behulp van de methode [12]. Die SBOM blijft dan ook de beste plek om te starten [13], zodat in ieder geval kan worden gereageerd bij een High/High advisory [14] op de vraag “Gebruiken wij dit ook?”
De stap naar proactief onderzoek kan worden gezet wanneer reactieve capaciteiten zoals SBOM op orde zijn. Het is niet waarschijnlijk dat elke afnemer van een Linux distributie de software op een vergelijkbare manier doorlicht, maar het geeft aanleiding tot het stellen van vragen aan kritieke partners in uw ICT-toeleveringsketen.
Doet u onderzoek naar dit beveiligingsprobleem en heeft u vragen of eventueel bevindingen die u met ons wil delen? Neem dan contact op met het NCSC.
Dit expertblog werd geschreven door:
Daniël Sierat – CTI Specialist
Ruben Faber – Strategisch Adviseur Cybersecurity
Bas Schalbroeck – Senior CTI Specialist
Bronnen
[1] [SECURITY] [DSA 5649-1] xz-utils security update (debian.org)
[2] CVE-2024-3094- Red Hat Customer Portal
[3] openSUSE addresses supply chain attack against xz compression library - openSUSE News
[4] All about the xz-utils backdoor | Kali Linux Blog
[5] Arch Linux - News: The xz package has been backdoored
[7] research!rsc: Timeline of the xz open source attack (swtch.com)
[8] KB: Metrics and Metrics Models - CHAOSS
[9] Factsheet Open Source Security | Factsheet | Nationaal Cyber Security Centrum (ncsc.nl)
[10] Metric: Bus Factor - CHAOSS
[11] Metric: Elephant Factor - CHAOSS
[13] SBOM startergids | Wat doet het NCSC voor jou? | Nationaal Cyber Security Centrum
[14] NCSC Advisories