Kees laver mad Jeg laver et blogindlæg, hvor har rejst bekymringer om fejlrettelsesprocessen igangværende i de stabile grene af Linux -kernen og er det nævne, at uge for uge er omkring hundrede rettelser inkluderet på stabile grene, hvilket er for meget og kræver en stor indsats for at vedligeholde Linux-kernebaserede produkter.
Ifølge Kees, processen med håndtering af kernefejl omgås og kernen mangler mindst 100 yderligere udviklere at arbejde koordineret på dette område. Udover at nævne, at større kerneudviklere regelmæssigt retter fejl, men der er ingen garanti for, at disse rettelser overføres til tredjeparts kernelvarianter.
Derved nævner han, at brugere af forskellige Linux-kernebaserede produkter heller ikke har nogen måde at kontrollere, hvilke fejl der er rettet, og hvilken kerne der bruges på deres enheder. I sidste ende er leverandører ansvarlige for deres produkters sikkerhed, men står over for en meget høj patches på stabile kernegrener, de står over for valget om at migrere alle patches, selektivt migrere de vigtigste eller ignorere alle patches. .
Upstream -kerneudviklere kan rette fejl, men de har ikke kontrol over, hvad en downstream -sælger vælger at indarbejde i deres produkter. Slutbrugere kan vælge deres produkter, men de har generelt ingen kontrol over, hvilke fejl der er rettet, eller hvilken kerne der bruges (et problem i sig selv). I sidste ende er leverandører ansvarlige for at holde deres produktkerner sikre.
Kees laver mad antyder, at den optimale løsning ville være at overføre kun de vigtigste rettelser og sårbarheder, men hovedproblemet er at adskille disse fejl fra det generelle flow, da de fleste af de nye problemer er en konsekvens af brugen af C -sproget, som kræver meget omhu, når man arbejder med hukommelse og tips.
For at gøre sagen værre er mange potentielle sårbarhedsrettelser ikke mærket med CVE -identifikatorer eller modtager ikke et CVE -id nogen tid efter, at programrettelsen er frigivet.
I et sådant miljø er det meget svært for producenter at adskille mindre rettelser fra større sikkerhedsproblemer. Ifølge statistik fjernes mere end 40% af sårbarhederne før CVE -tildeling, og i gennemsnit er forsinkelsen mellem en rettelsesfrigivelse og en CVE -opgave tre måneder (det vil sige i begyndelsen opfatter en løsning som en almindelig fejl,
Som et resultat ikke at have en separat gren med rettelser til sårbarhederne og ikke modtager oplysninger om forbindelsen til sikkerheden ved dette eller det problem, producenter af Linux-kernebaserede produkter skal løbende overføre alle rettelser af de nye staldgrene. Men dette arbejde er arbejdskrævende og står over for modstand fra virksomheder på grund af frygt for regressive ændringer, der kan forstyrre produktets normale drift.
Nøgler Cook mener, at den eneste løsning til at holde kernen sikker til en rimelig pris på lang sigt er at flytte patch -ingeniører til skøre kernel buildsl at arbejde sammen på en koordineret måde at opretholde patches og sårbarheder i upstream -kernen. Som det er nu, bruger mange leverandører ikke de nyeste kernelversioner i deres produkter og backport -rettelser på egen hånd, hvilket betyder, at ingeniører fra forskellige virksomheder viser sig at kopiere hinandens arbejde og løse det samme problem.
For eksempel, hvis 10 virksomheder, hver med en ingeniør, der understøtter de samme rettelser, omdirigerer disse ingeniører til at reparere fejl opstrøms, i stedet for at migrere en rettelse, kunne de rette 10 forskellige fejl til den samlede fordel eller gå sammen om at gennemgå fejlene. Foreslåede ændringer . Og undgå at inkludere buggy -kode i kernen. Ressourcerne kunne også bruges til at oprette nye kodeanalyse- og testværktøjer, der automatisk på et tidligt tidspunkt ville opdage de typiske fejlklasser, der dukker op igen og igen.
Nøgler Cook foreslår også mere aktivt at bruge automatiseret test og fuzzing direkte i kerneudviklingsprocessen, brug kontinuerlige integrationssystemer og opgive den arkaiske forvaltning af udviklingen via e-mail.
kilde: https://security.googleblog.com