Inferring 1-Minimal Trigger Configurations for Assessing Linux Kernel CVE Triggerability
Dit artikel presenteert FCC, een framework dat 1-minimale, aan het build-systeem voldoende kernelconfiguraties afleidt om de triggerbaarheid van Linux-kernel CVE's in op productie afgestemde omgevingen nauwkeurig te beoordelen, waarbij de succespercentages van configuraties aanzienlijk worden verbeterd en de kandidaat-optiesets worden verminderd in vergelijking met bestaande baselines.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
In de uitgestrekte, onzichtbare architectuur van de digitale wereld fungeert de Linux-kernel als het fundamentele besturingssysteem voor alles, van supercomputers tot de smartphones in onze zakken. Het is een enorme, complexe stuk software die beheert hoe hardware en software met elkaar communiceren. Omdat het zo cruciaal is, zoeken beveiligingsonderzoekers constant naar gebreken, bekend als kwetsbaarheden, die aanvallers zouden kunnen toestaan om binnen te dringen. Wanneer een gebrek wordt gevonden, krijgt het een uniek identificatienummer, vergelijkbaar met een serienummer op een product, en wordt het toegevoegd aan een publieke database. Het weten dat er echter een gebrek bestaat in een specifieke versie van de software, is slechts de helft van de strijd. De echte vraag voor de bedrijven die het internet beheren, is of dat gebrek daadwerkelijk getriggerd kan worden op hun specifieke machines. Alleen omdat een gebrek in de code bestaat, betekent niet dat het actief is; het vereist vaak een zeer specifieke, verborgen combinatie van instellingen die aanstaan om het gebrek te laten ontwaken en schade te veroorzaken.
Jarenlang hebben beveiligingsteams gestreden met een frustrerende kloof. De mensen die deze gebreken vinden, testen ze meestal in een generieke, algemene omgeving die is ontworpen om zoveel mogelijk bugs te vangen. Maar de bedrijven die de software daadwerkelijk gebruiken, draaien zeer aangepaste versies, die zijn gestript en afgestemd op specifieke taken zoals het draaien van cloudservers of het beheren van netwerkverkeer. Een gebrek dat gemakkelijk te triggeren is in een generieke test, kan in een aangepast systeem volkomen onschadelijk zijn omdat de benodigde instellingen nooit aan zijn gezet. Omgekeerd kan een gebrek latent aanwezig zijn in een generieke test, maar gevaarlijk worden in een specifieke aangepaste opstelling. De uitdaging is geweest om precies uit te vogelen welke instellingen actief moeten zijn om een specifiek gebrek werkend te maken, zonder dat men handmatig door duizenden mogelijke opties hoeft te gissen.
Een team van onderzoekers van de Nanjing University of Science and Technology en de Shandong Normal University heeft een nieuwe methode ontwikkeld om deze kloof te overbruggen. Ze hebben een geautomatiseerd systeem gecreëerd dat fungeert als een nauwkeurige vertaler, die een bekende beveiligingsfout neemt en de exacte, minimale set instellingen bepaalt die nodig is om dat gebrek actief te maken op een specifieke versie van de Linux-kernel. Hun doel was niet alleen om een lijst met instellingen te vinden, maar om de kleinste mogelijke lijst te vinden die nog steeds werkt. Ze noemen dit een "minimale triggerconfiguratie". De onderzoekers wilden ervoor zorgen dat als een bedrijf een specifieische set instellingen heeft, zij met zekerheid kunnen weten of een specifieke kwetsbaarheid getriggerd kan worden op hun systeem, of dat hun huidige configuratie hen van nature beschermt.
De onderzoekers bouwden een framework dat ze FCC noemden om dit probleem op te lossen. Het proces begint door het systeem informatie te voeren over een specifiek beveiligingsgebrek, inclusief de beschrijving en eventuele beschikbare code die demonstreert hoe het gebrek getriggerd kan worden. Het systeem scant vervolgens de enorme documentatie van de Linux-kernel om te identificeren welke instellingen gerelateerd kunnen zijn aan dat gebrek. In het verleden vertrouwden onderzoekers op statische kaarten van hoe instellingen van elkaar afhankelijk zijn, maar dit leidde vaak tot lijsten die te lang waren en veel onnodige opties bevatten. Het nieuwe systeem gebruikt een geavanceerdere aanpak om de details van de kwetsbaarheid te lezen en deze direct te koppelen aan de specifieke code en instellingen die er toe doen.
Een kritiek onderdeel van het proces omvat een stap die eerdere pogingen vaak doet mislukken. Wanneer een lijst met instellingen op een kernel wordt toegepast, past het systeem deze automatisch aan om te garanderen dat ze geldig zijn. Dit aanpassingsproces, bekend als "making old configuration", kan instellingen die afhankelijk zijn van andere instellingen die niet aan staan, geruisloos uitschakelen. De nieuwe methode van de onderzoekers anticipeert hierop. Het somt niet alleen de instellingen op; het controleert actief of de instellingen dit automatische aanpassingsproces overleven. Als een instelling door het systeem wordt uitgeschakeld, bepaalt het framework welke andere instellingen aan moeten staan om deze in leven te houden, waardoor de lijst effectief wordt gerepareerd totdat deze stabiel en klaar is voor de bouw.
Zodra het systeem een stabiele lijst met instellingen heeft die gebouwd kan worden, gaat het naar de laatste en meest rigoureuze fase: het testen. Het systeem bouwt een versie van de kernel met die instellingen, start deze op in een veilige, geïsoleerde virtuele omgeving en voert de code uit die ontworpen is om het gebrek te triggeren. Als het gebrek triggert, weet het systeem dat de instellingen correct zijn. Als dat niet gebeurt, begint het systeem met een proces van eliminatie. Het verwijdert één voor één een instelling en probeert het opnieuw. Als het gebrek nog steeds triggert zonder die instelling, was de instelling overbodig en wordt deze weggegooid. Dit gaat door totdat het systeem arriveert bij de kleinste mogelijke groep instellingen die nog steeds het gebrek doet verschijnen. Deze laatste groep is wat de onderzoekers de "one-minimal" grens noemen, die de absolute kernvereisten vertegenwoordigt voor het bestaan van de kwetsbaarheid.
Het team testte hun methode op 88 verschillende historische beveiligingsgebreken in diverse versies van de Linux-kernel. Ze vergeleken hun resultaten met bestaande methoden en zagen een significante verbetering. Bij het gebruik van oudere technieken slaagde het systeem er slechts in om voor ongeveer 62 procent van de gebreken een werkende configuratie te produceren die het automatische aanpassingsproces overleefde. Met hun nieuwe methode steeg dit succespercentage naar bijna 97 procent. Bovendien waren de lijsten met instellingen die zij produceerden veel korter. Gemiddeld verminderde de nieuwe methode het aantal benodigde instellingen van bijna 70 naar slechts 15, en na de laatste testfase werd het vaak teruggebracht tot minder dan twee instellingen per gebrek. Dit betekent dat in plaats van dat een beveiligingsteam tientallen potentiële schakelaars moet controleren, ze een zeer korte, duidelijke lijst kunnen raadplegen om te bepalen of hun systeem een risico loopt.
De onderzoekers analyseerden ook hoeveel tijd en rekenkracht het proces vereiste. Ze ontdekten dat de eerste stap van het lezen van de beschrijvingen van de kwetsbaarheden en het raden van de instellingen de meeste tijd kostte, maar ze lieten zien dat deze kosten aanzienlijk kunnen worden verminderd door irrelevante informatie weg te filteren voordat de computer aan het werk gaat. De laatste stap van het bouwen en testen van de kernel was de meest intensieve qua middelen, aangezien het daadwerkelijk draaien van de software vereiste, maar dit was noodzakelijk om te bewijzen dat het gebrek echt was. De studie bevestigt dat hoewel het proces complex is, het betrouwbaar is en resultaten oplevert die zowel effectief als controleerbaar zijn.
Dit werk biedt een duidelijk pad voor organisaties om hun risico te beoordelen zonder dat zij experts hoeven te zijn in de diepe interne werking van de Linux-kernel. Door een vage vraag over een kwetsbaarheid om te zetten in een concrete, testbare configuratie, hebben de onderzoekers beveiligingsteams een instrument gegeven om betere beslissingen te nemen. Ze kunnen nu exact in kaart brengen welke delen van hun systeem blootgesteld zijn aan een specifieke dreiging en welke deel uitmaken van de natuurlijke bescherming door hun huidige opstelling. De studie concludeert dat hoewel de methode het beste werkt wanneer er een specifieke testcode beschikbaar is, het een robuuste manier biedt om de triggerbaarheid van kwetsbaarheden in de echte wereld te begrijpen, waarbij men verder kijkt dan eenvoudige versienummers naar de werkelijke configuratie van de machines die onze digitale infrastructuur draaien.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.