Kiss Cook fra Google har opfordret til at modernisere fejlbehandlingsprocessen i Linux-kernen

Kees Cook, tidligere hovedsystemadministrator for kernel.org og leder af Ubuntu Security Team, som nu arbejder hos Google med at sikre Android og ChromeOS, har udtrykt bekymring over den nuværende proces for fejlrettelser i de stabile versioner af kernen. Der tilføjes cirka et hundrede rettelser til de stabile versioner hver uge, og efter lukningen af ændringsvinduet til den næste udgivelse nærmer antallet sig tusinde (vedligeholdere holder rettelser tilbage indtil lukningen af vinduet, og efter dannelsen af '-rc1' offentliggør de det opsamlede på en gang), hvilket er for mange og kræver store arbejdstimer til vedligeholdelse af produkter baseret på Linux-kernen.

Ifølge Kees får processen til at arbejde med fejl i kernen ikke tilstrækkelig opmærksomhed, og kernen mangler mindst 100 yderligere udviklere til koordineret arbejde i dette område. De primære udviklere af kernen retter regelmæssigt fejl, men der er ingen garantier for, at disse rettelser vil blive overført til de kernelvarianter, der anvendes af tredjepartsproducenter. Brugerne af forskellige produkter baseret på Linux-kernen har heller ikke mulighed for at overvåge, hvilke fejl der er blevet rettet, og hvilken kerne der bruges i deres enheder. I sidste ende er det producenterne, der er ansvarlige for sikkerheden af deres produkter, men under de meget intensive publiceringsforhold for rettelser i de stabile versioner af kernen er de blevet stillet over for valget - at overføre alle rettelser, selektivt porte de vigtigste eller ignorere alle rettelser.

Den optimale løsning ville være kun at overføre de mest kritiske rettelser og sårbarheder, men det er netop her, at den største udfordring ligger i at identificere sådanne fejl. Det største antal uventede problemer stammer fra brugen af C-sproget, som kræver stor omhu ved håndtering af hukommelse og pegere. Situationen kompliceres af, at mange potentielle rettelser af sårbarheder ikke får tildelt CVE-identifikatorer eller først får en sådan identifikator lang tid efter, at rettelsen er offentliggjort. Under sådanne forhold er det meget svært for producenterne at skelne mellem sekundære rettelser og de kritiske problemer, der påvirker sikkerheden. Ifølge statistikker bliver mere end 40% af sårbarhederne rettet, inden der tildeles en CVE, og den gennemsnitlige forsinkelse mellem offentliggørelsen af en rettelse og tildelingen af en CVE er tre måneder (dvs. i starten opfattes rettelsen som en almindelig fejl, men først efter nogle måneder bliver det klart, at der er tale om en lukning af en sårbarhed).

Som et resultat af ikke at have en separat gren med rettelser til sårbarheder og uden at modtage oplysninger om forbindelse mellem sikkerhed og de specifikke problemer, står producenterne af produkter baseret på Linux-kernen tilbage med at skulle overføre alle rettelser fra de nyeste stabile grene kontinuerligt. Men dette arbejde kræver betydelige arbejdsressourcer og møder modstand i virksomhederne på grund af frygt for regresive ændringer, der kan forstyrre produktets normale funktion.

Lad os minde om, at ifølge Linus Torvalds er alle fejl vigtige, og sårbarheder bør ikke adskilles fra andre former for fejl og prioriteres i en særskilt kategori. Dette synspunkt forklares ved, at det for den almindelige udvikler, der ikke specialiserer sig i sikkerhedspørgsmål, ikke er indlysende, hvordan en rettelse kan have forbindelse til en potentiel sårbarhed (for mange rettelser kræver det særskilt audit at forstå, at de vedrører sikkerheden). Ifølge Linus bør sikkerhedsspecialister fra teamene, der er ansvarlige for vedligeholdelse af pakkefiler med kernen i Linux-distributionerne, håndtere spørgsmålet om at identificere de potentielle sårbarheder fra det samlede flow af rettelser.

Kees Cook mener, at den eneste løsning for at opretholde sikkerheden i kernen med rimelige langsigtede omkostninger er at overføre ingeniører, der arbejder med portering af rettelser til lokale kerneversioner, til en koordineret indsats for at vedligeholde rettelser og sårbarheder i den primære kerne (upstream). I sin nuværende form bruger mange producenter ikke de nyeste versioner af kernen i deres produkter og backporter rettelser på egen hånd, hvilket betyder, at ingeniører i forskellige virksomheder duplikerer hinandens arbejde ved at løse det samme problem.

For eksempel, hvis 10 virksomheder, hvor hver har én ingeniør, der arbejder med backporting af de samme rettelser, omdirigerer disse ingeniører til at rette fejl i upstream, så kunne de i stedet for at portere én rettelse, rette 10 forskellige fejl til fælles fordel eller deltage i gennemgangen af foreslåede ændringer og forhindre, at fejlbehæftet kode bliver inkluderet i kernen. Ressourcerne kunne også rettes mod at skabe nye værktøjer til test og analyse af kode, som ville gøre det muligt at opdage typiske klasser af fejl, der dukker op gentagne gange, tidligt i processen.

Kees Cook foreslår også at bruge automatiseret og fuzzing-testning mere aktivt direkte i udviklingsprocessen af kernen, anvende kontinuerlig integrationssystemer og afvise det forældede udviklingsstyringssystem via email. I øjeblikket hindres effektiv testning af, at de primære testprocesser er adskilt fra udviklingen og finder sted først efter frigivelse af versioner. Kees anbefalede også, at man for at reducere antallet af fejl bruger programmeringssprog, der sikrer mere a high level of security, såsom Rust.

Kilde: opennet.ru