Kees Cook, voormalig hoofdsysteembeheerder van kernel.org en leider van het Ubuntu Security Team dat nu bij Google werkt om Android en ChromeOS te beveiligen, uitte zijn bezorgdheid over het huidige proces van het oplossen van bugs in de stabiele takken van de kernel. Elke week worden er ongeveer honderd fixes opgenomen in de stabiele takken, en nadat het venster voor het accepteren van wijzigingen in de volgende release is gesloten, nadert het de duizend (de beheerders houden de fixes vast totdat het venster wordt gesloten en na de vorming van “ -rc1” ze publiceren de verzamelde exemplaren in één keer), wat te veel is en veel arbeid vereist voor onderhoudsproducten gebaseerd op de Linux-kernel.
Volgens Keys krijgt het proces van het werken met fouten in de kernel niet de nodige aandacht en mist de kernel minstens 100 extra ontwikkelaars voor gecoördineerd werk op dit gebied. De belangrijkste kernelontwikkelaars repareren regelmatig bugs, maar er is geen garantie dat deze fixes zullen worden overgedragen naar kernelvarianten die door derden worden gebruikt. Gebruikers van verschillende producten gebaseerd op de Linux-kernel hebben ook geen manier om te bepalen welke bugs worden opgelost en welke kernel op hun apparaten wordt gebruikt. Uiteindelijk zijn fabrikanten verantwoordelijk voor de veiligheid van hun producten, maar door de zeer hoge intensiteit van het publiceren van fixes in stabiele kernelvertakkingen, werden ze geconfronteerd met de keuze: alle fixes porteren, selectief de belangrijkste porteren, of alle fixes negeren. .
De optimale oplossing zou zijn om alleen de belangrijkste oplossingen en kwetsbaarheden te migreren, maar het isoleren van dergelijke fouten uit de algemene stroom is het grootste probleem. Het grootste aantal problemen dat opduikt, is een gevolg van het gebruik van de C-taal, wat grote zorgvuldigheid vereist bij het werken met geheugen en pointers. Tot overmaat van ramp zijn veel potentiële kwetsbaarheidspatches niet voorzien van een CVE-identifier, of krijgen ze enige tijd nadat de patch is gepubliceerd een CVE-identifier toegewezen. In een dergelijke omgeving is het voor fabrikanten erg moeilijk om kleine oplossingen te scheiden van belangrijke beveiligingsproblemen. Volgens statistieken wordt meer dan 40% van de kwetsbaarheden verholpen voordat een CVE wordt toegewezen, en bedraagt de vertraging tussen de release van een oplossing en de toewijzing van een CVE gemiddeld drie maanden (d.w.z. dat de oplossing in eerste instantie wordt gezien als een reguliere bug, maar pas na enkele maanden wordt duidelijk dat de kwetsbaarheid is verholpen).
Als gevolg hiervan moeten fabrikanten van producten op basis van de Linux-kernel, zonder een aparte tak met oplossingen voor kwetsbaarheden en zonder informatie te ontvangen over de beveiligingsverbinding van een bepaald probleem, voortdurend alle oplossingen van de nieuwste stabiele takken overbrengen. Maar dit werk vergt veel arbeid en stuit op weerstand bij bedrijven vanwege de angst voor de opkomst van regressieve veranderingen die de normale werking van het product zouden kunnen verstoren.
Laten we niet vergeten dat volgens Linus Torvalds alle fouten belangrijk zijn en dat kwetsbaarheden niet gescheiden mogen worden van andere soorten fouten en toegewezen moeten worden aan een aparte categorie met hogere prioriteit. Deze mening wordt verklaard door het feit dat voor een gewone ontwikkelaar die niet gespecialiseerd is in beveiligingsproblemen, het verband tussen een oplossing en een potentiële kwetsbaarheid niet voor de hand ligt (voor veel oplossingen maakt alleen een afzonderlijke audit het mogelijk om te begrijpen dat ze betrekking hebben op de beveiliging ). Volgens Linus zouden beveiligingsspecialisten van de teams die verantwoordelijk zijn voor het onderhoud van kernelpakketten in Linux-distributies betrokken moeten worden bij het identificeren van potentiële kwetsbaarheden uit de algemene stroom patches.
Kees Cook is van mening dat de enige oplossing voor het behoud van de kernelbeveiliging tegen redelijke kosten op de lange termijn erin bestaat dat bedrijven de technici die betrokken zijn bij het porten van fixes naar lokale kernelbuilds, overbrengen naar een gezamenlijke, gecoördineerde inspanning om fixes en kwetsbaarheden in de hoofdkernel (upstream) te onderhouden. ). In de huidige vorm gebruiken veel fabrikanten niet de nieuwste kernelversies in hun producten en backporteren ze de oplossingen intern, d.w.z. Het blijkt dat ingenieurs in verschillende bedrijven elkaars werk dupliceren en hetzelfde probleem oplossen.
Als bijvoorbeeld tien bedrijven, elk met één ingenieur die dezelfde oplossingen backporteert, deze technici opnieuw zouden toewijzen om bugs upstream te repareren, dan zouden ze in plaats van één oplossing over te dragen, 10 verschillende bugs kunnen repareren voor het gemeenschappelijke voordeel of kunnen deelnemen aan de beoordeling van voorgestelde wijzigingen en voorkomen dat code met fouten in de kernel wordt opgenomen. Er zouden ook middelen kunnen worden besteed aan het creëren van nieuwe tools voor het testen en analyseren van code, waarmee vroegtijdige detectie mogelijk wordt gemaakt van algemene soorten fouten die steeds weer opduiken.
Kees Cook stelt ook voor om actiever gebruik te maken van geautomatiseerde en fuzzing-tests direct in het kernelontwikkelingsproces, door continue integratiesystemen te gebruiken en het archaïsche ontwikkelingsbeheer via e-mail achterwege te laten. Momenteel wordt effectief testen belemmerd door het feit dat de belangrijkste testprocessen gescheiden zijn van de ontwikkeling en plaatsvinden nadat de releases zijn gevormd. Keys raadde ook aan om bij de ontwikkeling talen te gebruiken die een hoger beveiligingsniveau bieden, zoals Rust, om het aantal fouten te verminderen.
Bron: opennet.ru