Kis Cook van Google heeft opgeroepen tot modernisering van het foutafhandelingsproces in de Linux-kernel

Kees Cook, voormalig hoofd systeembeheerder van kernel.org en leider van het Ubuntu Security Team, die nu bij Google werkt aan de beveiliging van Android en ChromeOS, heeft zijn bezorgdheid geuit over het huidige proces van foutopsporing in de stabiele takken van de kernel. Elke week worden er ongeveer honderd foutoplossingen opgenomen in de stabiele takken, en na het sluiten van het venster voor wijziging bij de volgende release komt het aantal zelfs dicht bij duizend (de ontwikkelaars houden de correcties vast tot het sluiten van het venster, en na de vorming van ‘-rc1’ publiceren ze alles in één keer), wat te veel is en een grote inspanning vereist voor het onderhoud van producten op basis van de Linux-kernel.

Volgens Kees krijgt het proces van werken met fouten in de kernel niet de juiste aandacht en ontbreekt het de kernel aan ten minste honderd extra ontwikkelaars voor gecoördineerd werk op dit gebied. De belangrijkste ontwikkelaars van de kernel corrigeren regelmatig fouten, maar er zijn geen garanties dat deze correcties worden overgenomen in de kernelversies die door externe fabrikanten worden gebruikt. Gebruikers van verschillende producten op basis van de Linux-kernel hebben ook niet de mogelijkheid om te controleren welke fouten zijn opgelost en welke kernel op hun apparaten wordt gebruikt. Uiteindelijk zijn de fabrikanten verantwoordelijk voor de veiligheid van hun producten, maar door de zeer hoge frequentie van publicatie van correcties in de stabiele takken van de kernel staan zij voor de keuze: alle correcties overnemen, selectief de belangrijkste porteren of alle correcties negeren.

De optimale oplossing zou zijn om alleen de meest kritieke patches en kwetsbaarheden over te dragen, maar de kern van het probleem ligt in het identificeren van dergelijke fouten uit de algemene toestroom. Het grootste aantal opduikende problemen is het gevolg van het gebruik van de programmeertaal C, die grote nauwkeurigheid vereist bij het werken met geheugen en pointers. De situatie wordt verergerd doordat veel potentiële patches voor kwetsbaarheden geen CVE-identificaties krijgen, of dat een dergelijke identificatie enige tijd na de publicatie van de patch wordt toegekend. In dergelijke omstandigheden is het voor fabrikanten zeer moeilijk om secundaire patches van belangrijke veiligheidstekens te scheiden. Statistisch gezien wordt meer dan 40% van de kwetsbaarheden opgelost voordat ze een CVE-nummer krijgen, en de gemiddelde vertraging tussen de uitgave van een patch en de toewijzing van een CVE bedraagt drie maanden (dit betekent dat de patch aanvankelijk als een gewone bug wordt gezien, maar pas maanden later duidelijk wordt dat het om het oplossen van een kwetsbaarheid ging).

Uiteindelijk, zonder een aparte ветка met patches voor kwetsbaarheden en zonder informatie over de relatie met de beveiliging van een bepaald probleem, blijven fabrikanten van producten die zijn gebaseerd op de Linux-kernel voortdurend alle patches vanuit nieuwe stabiele branches overdragen. Maar dit werk vereist veel mankracht en stuit binnen bedrijven op weerstand vanwege de vrees voor regressieve veranderingen die de normale werking van het product kunnen verstoren.

Laten we niet vergeten dat, volgens Linus Torvalds, alle fouten belangrijk zijn en kwetsbaarheden niet van andere soorten fouten moeten worden gescheiden en in een aparte, hogere prioriteitscategorie moeten worden geplaatst. Deze mening wordt verklaard doordat voor een gewone ontwikkelaar, die niet gespecialiseerd is in beveiligingskwesties, de relatie tussen de patch en een potentiële kwetsbaarheid niet duidelijk is (voor veel patches maakt alleen een aparte audit duidelijk dat ze betrekking hebben op veiligheid). Volgens Linus moeten beveiligingsexperts van de teams die verantwoordelijk zijn voor de ondersteuning van pakketbeheer met de kernel in Linux-distributies zich bezighouden met het identificeren van kwetsbaarheden binnen de algemene toestroom van patches.

Kees Cook is van mening dat de enige oplossing voor het waarborgen van de beveiliging van de kernel tegen redelijke lange termijn kosten is dat bedrijven engineers, die verantwoordelijk zijn voor het porteren van patches naar lokale kernel-builds, heroriënteren naar een gezamenlijke gecoördineerde aanpak voor het onderhouden van patches en kwetsbaarheden in de upstream kernel. Momenteel gebruiken veel fabrikanten oudere versies van de kernel in hun producten en backporten ze patchen zelf, wat betekent dat engineers in verschillende bedrijven elkaars werk dupliceren door hetzelfde probleem op te lossen.

Bijvoorbeeld, als 10 bedrijven, elk met één engineer die dezelfde patches backport, deze engineers heroriënteren naar het oplossen van bugs in de upstream, zouden ze in plaats van één patch te porteren 10 verschillende bugs voor een gemeenschappelijk belang kunnen oplossen of zich kunnen aansluiten bij de review van voorgestelde veranderingen om te voorkomen dat buggy code in de kernel wordt opgenomen. Ook zouden de middelen kunnen worden ingezet voor het ontwikkelen van nieuwe test- en code-analysehulpmiddelen die in een vroeg stadium automatisch typische klassen bugs kunnen identificeren die steeds weer opduiken.

Kees Cook stelt ook voor om geautomatiseerd en fuzzing-testing actiever in het ontwikkelingsproces van de kernel te gebruiken, systemen voor continue integratie toe te passen en af te stappen van de verouderde e-mailverdeling in de ontwikkeling. Momenteel wordt effectief testen bemoeilijkt doordat de belangrijkste testprocessen gescheiden zijn van de ontwikkeling en plaatsvinden na de release. Kees raadde ook aan om programmeertalen te gebruiken die meer veiligheid bieden tijdens de ontwikkeling, een hoog niveau van beveiliging, zoals Rust.

Bron: opennet.ru