Kis Cook di Google ha invitato a modernizzare il processo di gestione degli errori nel kernel di Linux

Kees Cook, ex capo amministratore di sistema di kernel.org e leader del Ubuntu Security Team, attualmente lavora presso Google per garantire la sicurezza di Android e ChromeOS. Ha espresso preoccupazione per l'attuale processo di correzione degli errori nei rami stabili del kernel. Ogni settimana vengono inclusi circa cento correttivi nei rami stabili, e dopo la chiusura della finestra di accettazione delle modifiche, si avvicina a mille (i manutentori trattengono le correzioni fino alla chiusura della finestra, e dopo la generazione di "-rc1" pubblicano tutto insieme), il che è troppo e richiede un notevole dispendio di risorse per il supporto dei prodotti basati sul kernel Linux.

Secondo Kees, non viene prestata la giusta attenzione al processo di lavoro sugli errori del kernel, e mancano almeno 100 sviluppatori aggiuntivi per un lavoro coordinato in questo settore. I principali sviluppatori del kernel correggono regolarmente gli errori, ma non ci sono garanzie che queste correzioni vengano trasferite nelle varianti del kernel utilizzate dai produttori di terze parti. Gli utenti di diversi prodotti basati su kernel Linux non hanno nemmeno la possibilità di monitorare quali errori sono stati corretti e quale kernel è utilizzato nei loro dispositivi. Alla fine, i produttori sono responsabili della sicurezza dei propri prodotti, ma, date le elevate frequenze di pubblicazione delle correzioni nei rami stabili del kernel, si trovano di fronte a una scelta difficile: implementare tutte le correzioni, portare solo quelle più importanti o ignorare del tutto tutte le correzioni.

La soluzione ottimale sarebbe quella di trasferire solo le correzioni e le vulnerabilità più importanti, ma il problema principale consiste nell'identificare tali errori all'interno del flusso generale. Il numero maggiore di problemi emergenti è il risultato dell'uso del linguaggio C, che richiede grande attenzione nella gestione della memoria e dei puntatori. A complicare la situazione c'è il fatto che molte potenziali correzioni delle vulnerabilità non vengono fornite con identificatori CVE o ottengono simili identificatori solo dopo un certo periodo dalla pubblicazione della correzione. In tali condizioni, è molto difficile per i produttori distinguere le correzioni secondarie dai problemi importanti legati alla sicurezza. Statistiche indicano che oltre il 40% delle vulnerabilità viene risolto prima di ottenere un CVE e in media il ritardo tra la pubblicazione della correzione e l'assegnazione del CVE è di tre mesi (cioè inizialmente la correzione viene percepita come un errore ordinario, ma solo dopo alcuni mesi diventa chiaro che si trattava di una vulnerabilità risolta).

Di conseguenza, non avendo un ramo separato per le correzioni delle vulnerabilità e non ricevendo informazioni sul legame di sicurezza di un determinato problema, i produttori di prodotti basati sul kernel Linux sono costretti a trasferire continuamente tutte le correzioni dai nuovi rami stabili. Tuttavia, questo lavoro richiede notevoli risorse e incontra resistenze nelle aziende a causa della paura di possibili cambiamenti regressivi, in grado di compromettere il normale funzionamento del prodotto.

Ricordiamo che secondo Linus Torvalds, tutti gli errori sono importanti e le vulnerabilità non dovrebbero essere separate da altri tipi di errori e collocate in una categoria a priorità maggiore. Questa opinione è motivata dal fatto che per uno sviluppatore medio, non specializzato in questioni di sicurezza, non è chiaro il legame tra una correzione e una potenziale vulnerabilità (per molte correzioni solo un audit separato consente di comprendere che riguardano la sicurezza). Secondo Linus, la questione dell'individuazione delle vulnerabilità potenziali all'interno del flusso generale delle correzioni dovrebbe essere gestita da esperti di sicurezza delle squadre responsabili del supporto ai pacchetti del kernel nelle distribuzioni Linux.

Kees Cook ritiene che l'unica soluzione per mantenere la sicurezza del kernel a costi ragionevoli a lungo termine sia il trasferimento degli ingegneri delle aziende impegnati nella portabilità delle patch alle versioni locali del kernel, per una collaborazione coordinata nella gestione delle patch e delle vulnerabilità nel kernel principale (upstream). Attualmente, molti produttori utilizzano versioni non aggiornate del kernel nei loro prodotti e portano indietro le patch con le proprie forze, il che significa che gli ingegneri di diverse aziende duplicano il lavoro l'uno dell'altro, affrontando lo stesso problema.

Ad esempio, se 10 aziende, ognuna con un ingegnere impegnato nella portabilità delle stesse patch, reindirizzassero quegli ingegneri alla correzione di errori nell'upstream, potrebbero invece risolvere 10 diversi errori a beneficio collettivo o partecipare alla revisione delle modifiche proposte, evitando così l'inclusione di codice errato nel kernel. Le risorse potrebbero anche essere dirette verso la creazione di nuovi strumenti per il testing e l'analisi del codice, che consentirebbero di identificare automaticamente le classi comuni di errori che emergono ripetutamente.

Kees Cook propone anche di utilizzare più attivamente il testing automatizzato e il fuzzing direttamente nel processo di sviluppo del kernel, adottare sistemi di integrazione continua e abbandonare la gestione antiquata dello sviluppo tramite email. Attualmente, un'efficace attività di testing è ostacolata dal fatto che i processi di testing principali sono separati dallo sviluppo e avvengono solo dopo la creazione delle release. Kees ha anche raccomandato di utilizzare linguaggi che garantiscano una maggiore un alto livello di sicurezza, come Rust.

Fonte: opennet.ru