Kees Cook, ex amministratore di u sistema di kernel.org è capu di u Squadra di Sicurezza di Ubuntu chì avà travaglia in Google per assicurà Android è ChromeOS, hà manifestatu preoccupazione per u prucessu attuale di risolve i bug in i rami stabili di u kernel. Ogni settimana, circa un centu di correzioni sò inclusi in i rami stabili, è dopu chì a finestra per accettà i cambiamenti in a prossima versione hè chjusa, si avvicina à un mille (i mantenitori tenenu e correzioni finu à chì a finestra hè chjusa, è dopu a furmazione di " -rc1" anu publicatu l'accumulati in una volta), chì hè troppu è esige assai travagliu per i prudutti di mantenimentu basati nantu à u kernel Linux.
Sicondu Keys, u prucessu di travaglià cù l'errori in u kernel ùn hè micca datu l'attenzione è u kernel ùn manca almenu 100 sviluppatori supplementari per u travagliu coordinatu in questa zona. I sviluppatori principali di u kernel riparanu regularmente i bug, ma ùn ci hè micca garanzia chì queste correzioni seranu traspurtate à varianti di kernel utilizati da terze parti. L'utilizatori di diversi prudutti basati nantu à u kernel Linux ùn anu ancu manera di cuntrullà quale bug sò fissi è quale kernel hè utilizatu in i so dispositi. In ultimamente, i pruduttori sò rispunsevuli di a sicurità di i so prudutti, ma cù l'intensità assai alta di publicazione di correzioni in rami stabili di u kernel, anu affruntatu una scelta - portà tutte e correzioni, portu selettivamente i più impurtanti, o ignora tutte e correzioni. .
A suluzione ottima seria di migrà solu e correzioni è vulnerabili più impurtanti, ma l'isulazione di tali errori da u flussu generale hè u prublema principali. U più grande numaru di prublemi chì spuntanu sò una cunsequenza di l'usu di a lingua C, chì esige una grande cura quandu u travagliu cù memoria è puntatori. Per aggravà e cose, parechji patch di vulnerabilità potenziale ùn sò micca furniti cù un identificatore CVE, o sò assignati un identificatore CVE qualchì tempu dopu chì u patch hè publicatu. In un tali ambiente, hè assai difficiuli per i pruduttori di separà correzioni minori da prublemi di sicurezza impurtanti. Sicondu statistiche, più di 40% di e vulnerabilità sò riparati prima di l'assignazione di un CVE, è in media u ritardu trà a liberazione di una correzione è l'assignazione di un CVE hè di trè mesi (vale à dì, in prima a correzione hè percepita cum'è un bug regulare, ma solu dopu à parechji mesi diventa chjaru chì a vulnerabilità hè stata riparata).
In u risultatu, senza un ramu separatu cù correzioni per i vulnerabili è senza riceve infurmazione nantu à a cunnessione di sicurezza di un prublema particulari, i pruduttori di prudutti basati nantu à u kernel Linux sò lasciati per trasfiriri continuamente tutte e correzioni da l'ultimi rami stabili. Ma stu travagliu esige assai travagliu è face a resistenza in l'imprese per u timore di l'emergenza di cambiamenti regressivi chì puderanu disturbà u funziunamentu normale di u pruduttu.
Ricurdemu chì sicondu Linus Torvalds, tutti l'errori sò impurtanti è i vulnerabili ùn devenu esse separati da altri tipi d'errori è attribuiti à una categuria di priorità più alta separata. Questa opinione hè spiegata da u fattu chì per un sviluppatore ordinariu chì ùn hè micca specializatu in prublemi di sicurezza, a cunnessione trà una correzione è una vulnerabilità potenziale ùn hè micca ovvia (per parechje correzioni, solu un auditu separatu permette di capiscenu chì si tratta di sicurezza. ). Sicondu Linus, i specialisti di sicurezza da e squadre rispunsevuli di mantene i pacchetti di kernel in distribuzioni Linux anu da esse implicati in l'identificazione di vulnerabili potenziali da u flussu generale di patches.
Kees Cook crede chì l'unica soluzione per mantene a sicurità di u kernel à un costu raghjone à longu andà hè per l'imprese di trasfurmà l'ingegneri implicati in u porting di correzioni à e custruzzioni di u kernel lucale in un sforzu cumunu è coordinatu per mantene correzioni è vulnerabilità in u kernel principale (upstream). ). In a so forma attuale, assai pruduttori ùn utilizanu micca l'ultime versioni di u kernel in i so prudutti è backport i correzioni in-house, i.e. Ci hè chì l'ingegneri in diverse cumpagnie duplicate u travagliu di l'altri, risolve u listessu prublema.
Per esempiu, se 10 cumpagnie, ognuna cù un ingegnere chì portanu e stesse correzioni, anu riassignatu quelli ingegneri per risolve i bug in upstream, allora invece di backporting una correzione, puderanu correggere 10 bug differenti per u benefiziu cumuni o unisce à a revisione di pruposti. cambiamenti è impediscenu u codice buggy da esse inclusu in u kernel. E risorse puderanu ancu esse dedicate à creà novi strumenti per pruvà è analizà u codice chì permettenu a rilevazione precoce di classi cumuni d'errori chì si sviluppanu una volta è una volta.
Kees Cook suggerisce ancu più attivamente utilizendu teste automatizati è fuzzing direttamente in u prucessu di sviluppu di u kernel, utilizendu sistemi d'integrazione cuntinui è abbandunendu a gestione di u sviluppu arcaicu per email. Attualmente, a prova efficace hè ostacolata da u fattu chì i prucessi principali di teste sò separati da u sviluppu è si verificanu dopu à a furmazione di e versioni. Chjavi ricumandemu ancu di utilizà lingue chì furnisce un livellu più altu di sicurità, cum'è Rust, quandu si sviluppanu per riduce u numeru di errori.
Source: opennet.ru