Kees lage mat Jeg lager et blogginnlegg der har reist bekymringer for feilrettingsprosessen pågår i de stabile grenene av Linux -kjernen og er det nevne at uke for uke er omtrent hundre rettelser inkludert på stabile grener, noe som er for mye og krever mye innsats for å vedlikeholde Linux-kjernebaserte produkter.
I følge Kees, blir kjernefeilhåndteringsprosessen omgått og kjernen mangler minst 100 ekstra utviklere å jobbe på en koordinert måte på dette området. I tillegg til å nevne at store kjerneutviklere regelmessig fikser feil, men det er ingen garanti for at disse rettelsene overføres til tredjeparts kjernevarianter.
På den måten nevner han at brukere av forskjellige Linux-kjernebaserte produkter heller ikke har mulighet til å kontrollere hvilke feil som er fikset og hvilken kjerne som brukes på enhetene deres. Til syvende og sist er leverandørene ansvarlige for sikkerheten til produktene sine, men overfor en veldig høy oppdateringsfrekvens på stabile kjernegrener, måtte de velge mellom å migrere alle oppdateringene, selektivt migrere de viktigste eller ignorere alle lappene. .
Oppstrøms kjerneutviklere kan fikse feil, men de har ingen kontroll over hva en nedstrømsleverandør velger å innlemme i produktene sine. Sluttbrukere kan velge sine produkter, men de har vanligvis ingen kontroll over hvilke feil som er fikset eller hvilken kjerne som brukes (et problem i seg selv). Til syvende og sist er leverandørene ansvarlige for å holde produktkjernene trygge.
Kees lage mat antyder at den optimale løsningen ville være å overføre bare de viktigste løsningene og sårbarhetene, men hovedproblemet er å skille disse feilene fra den generelle flyten, siden de fleste av de nye problemene er en konsekvens av bruk av C -språket, som krever mye forsiktighet når du arbeider med minne og tips.
For å gjøre saken verre, er mange potensielle sårbarhetsrettelser ikke merket med CVE -identifikatorer eller mottar ikke en CVE -identifikator en stund etter at oppdateringen er utgitt.
I et slikt miljø er det svært vanskelig for produsenter å skille mindre reparasjoner fra store sikkerhetsproblemer. I følge statistikk blir mer enn 40% av sårbarhetene fjernet før CVE -tildeling, og gjennomsnittlig er forsinkelsen mellom en reparasjon og en CVE -oppgave tre måneder (det vil si at i begynnelsen oppfatter en løsning som en vanlig feil,
Som et resultat ikke ha en egen gren med rettelser for sårbarhetene og ikke mottar informasjon om forbindelsen med sikkerheten til dette eller det problemet, produsenter av Linux-kjernebaserte produkter må kontinuerlig overføre alle rettelser av de nye stallgrenene. Men dette arbeidet er arbeidskrevende og møter motstand fra selskaper på grunn av frykt for regressive endringer som kan forstyrre normal drift av produktet.
Nøkler Cook mener at den eneste løsningen for å holde kjernen sikker til en rimelig pris på lang sikt er å flytte oppdateringsingeniører til galne kjerneoppbyggingerl å jobbe sammen på en koordinert måte for å opprettholde oppdateringer og sårbarheter i oppstrømskjernen. Som det ser ut, bruker ikke mange leverandører de nyeste kjerneversjonene i sine produkter og bakportrettinger på egen hånd, det vil si at det viser seg at ingeniører fra forskjellige selskaper kopierer hverandres arbeid og løser det samme problemet.
For eksempel, hvis 10 selskaper, hver med en ingeniør som støtter de samme reparasjonene, omdirigerer disse ingeniørene for å fikse feil oppstrøms, i stedet for å migrere en reparasjon, kan de fikse 10 forskjellige feil for den generelle fordelen eller komme sammen for å gjennomgå feilene. Foreslåtte endringer . Og unngå å inkludere buggykode i kjernen. Ressursene kan også brukes til å lage nye kodeanalyse- og testverktøy som automatisk vil oppdage de typiske feilklassene som dukker opp igjen og igjen på et tidlig stadium.
Nøkler Cook foreslår også å mer aktivt bruke automatisert testing og fuzzing direkte i kjerneutviklingsprosessen, bruk kontinuerlige integreringssystemer og forlat den arkaiske styringen av utviklingen via e-post.
Fuente: https://security.googleblog.com