Kees Cook, tidligere chefsystemadministrator for kernel.org og leder af Ubuntu Security Team, som nu arbejder hos Google for at sikre Android og ChromeOS, udtrykte bekymring over den nuværende proces med at rette fejl i de stabile grene af kernen. Hver uge er omkring hundrede rettelser inkluderet i de stabile filialer, og efter at vinduet for at acceptere ændringer i den næste udgivelse er lukket, nærmer det sig tusind (vedligeholderne holder rettelserne, indtil vinduet lukkes, og efter dannelsen af " -rc1” de udgiver de akkumulerede på én gang), hvilket er for mange og kræver meget arbejde for vedligeholdelsesprodukter baseret på Linux-kernen.
Ifølge Keys er processen med at arbejde med fejl i kernen ikke givet tilstrækkelig opmærksomhed, og kernen mangler mindst 100 yderligere udviklere til koordineret arbejde på dette område. De vigtigste kerneudviklere retter regelmæssigt fejl, men der er ingen garanti for, at disse rettelser vil blive overført til kernevarianter, der bruges af tredjeparter. Brugere af forskellige produkter baseret på Linux-kernen har heller ingen mulighed for at kontrollere, hvilke fejl der er rettet, og hvilken kerne der bruges i deres enheder. I sidste ende er producenterne ansvarlige for sikkerheden af deres produkter, men med den meget høje intensitet af udgivelse af rettelser i stabile kernegrene, stod de over for et valg - porter alle rettelserne, portér selektivt de vigtigste eller ignorer alle rettelserne .
Den optimale løsning ville være kun at migrere de vigtigste rettelser og sårbarheder, men at isolere sådanne fejl fra det generelle flow er hovedproblemet. Det største antal problemer, der dukker op, er en konsekvens af brugen af C-sproget, som kræver stor omhu, når man arbejder med hukommelse og pointere. For at gøre ondt værre er mange potentielle sårbarhedsrettelser ikke forsynet med en CVE-identifikator, eller de tildeles en CVE-identifikation et stykke tid efter, at patchen er offentliggjort. I et sådant miljø er det meget vanskeligt for producenter at adskille mindre rettelser fra vigtige sikkerhedsproblemer. Ifølge statistikker er mere end 40 % af sårbarhederne rettet, før en CVE er tildelt, og i gennemsnit er forsinkelsen mellem frigivelsen af en rettelse og tildelingen af en CVE tre måneder (dvs. i første omgang opfattes rettelsen som en almindelig fejl, men først efter flere måneder bliver det klart, at sårbarheden er blevet rettet).
Som et resultat, uden en separat gren med rettelser til sårbarheder og uden at modtage information om sikkerhedsforbindelsen af et bestemt problem, er producenter af produkter baseret på Linux-kernen overladt til løbende at overføre alle rettelser fra de seneste stabile grene. Men dette arbejde kræver meget arbejdskraft og møder modstand i virksomheder på grund af frygt for fremkomsten af regressive ændringer, der kan forstyrre den normale drift af produktet.
Lad os huske på, at ifølge Linus Torvalds er alle fejl vigtige, og sårbarheder bør ikke adskilles fra andre typer fejl og tildeles en særskilt kategori med højere prioritet. Denne udtalelse forklares med, at for en almindelig udvikler, der ikke er specialiseret i sikkerhedsspørgsmål, er sammenhængen mellem en rettelse og en potentiel sårbarhed ikke indlysende (for mange rettelser er det kun en separat revision, der gør det muligt at forstå, at de vedrører sikkerhed ). Ifølge Linus bør sikkerhedsspecialister fra de teams, der er ansvarlige for at vedligeholde kernepakker i Linux-distributioner, være involveret i at identificere potentielle sårbarheder fra den generelle strøm af patches.
Kees Cook mener, at den eneste løsning til at opretholde kernesikkerhed til en rimelig langsigtet pris er, at virksomheder flytter de ingeniører, der er involveret i portering af rettelser til lokale kernebygninger til en fælles, koordineret indsats for at vedligeholde rettelser og sårbarheder i hovedkernen (opstrøms). ). I sin nuværende form bruger mange producenter ikke de nyeste kerneversioner i deres produkter og backporterer rettelserne internt, dvs. Det viser sig, at ingeniører i forskellige virksomheder duplikerer hinandens arbejde og løser det samme problem.
For eksempel, hvis 10 virksomheder, hver med én ingeniør, der backporterer de samme rettelser, omplacerede disse ingeniører til at rette fejl i upstream, så i stedet for at backportere én rettelse, kunne de rette 10 forskellige fejl til fælles fordel eller deltage i gennemgangen af foreslåede ændringer og forhindrer buggy-kode i at blive inkluderet i kernen. Ressourcer kunne også afsættes til at skabe nye værktøjer til at teste og analysere kode, som vil muliggøre tidlig opdagelse af almindelige fejlklasser, der dukker op igen og igen.
Kees Cook foreslår også mere aktivt at bruge automatiseret og fuzzing test direkte i kerneudviklingsprocessen, ved at bruge kontinuerlige integrationssystemer og opgive arkaisk udviklingsstyring via e-mail. I øjeblikket er effektiv test hæmmet af det faktum, at de vigtigste testprocesser er adskilt fra udvikling og opstår efter udgivelserne er dannet. Nøgler anbefales også at bruge sprog, der giver et højere sikkerhedsniveau, såsom Rust, ved udvikling for at reducere antallet af fejl.
Kilde: opennet.ru