Kees Cook di Google ha chiesto di modernizzare il processo di gestione degli errori nel kernel Linux

Kees Cook, ex capo amministratore di sistema di kernel.org e leader del Ubuntu Security Team, ora lavorando per Google per garantire la sicurezza di Android e ChromeOS, ha espresso preoccupazioni riguardo all'attuale processo di correzione dei bug nei rami stabili del kernel. Ogni settimana vengono inclusi circa cento fix nei rami stabili, e dopo la chiusura della finestra per l'accettazione delle modifiche, si avvicina a mille (i manutentori trattengono le correzioni fino alla chiusura della finestra, e dopo la formazione di "-rc1" pubblicano il tutto insieme), il che è troppo e richiede un impegno considerevole per il mantenimento dei prodotti basati su Linux.

Secondo Kisa, il processo di gestione degli errori nel kernel non riceve la giusta attenzione e mancano almeno 100 sviluppatori aggiuntivi per un lavoro coordinato in questo ambito. I principali sviluppatori del kernel correggono regolarmente gli errori, ma non ci sono garanzie che queste correzioni vengano trasferite nelle versioni del kernel utilizzate da produttori terzi. Gli utenti di vari prodotti basati su kernel Linux non hanno nemmeno la possibilità di controllare quali errori siano stati corretti e quale kernel sia utilizzato sui loro dispositivi. In ultima analisi, i produttori sono responsabili della sicurezza dei loro prodotti, ma di fronte all'elevata intensità di pubblicazione delle correzioni nelle branch stabili del kernel, si trovano di fronte a una scelta: implementare tutte le correzioni, portare selettivamente le più importanti oppure ignorare tutte le correzioni.

La soluzione ottimale sarebbe trasferire solo le correzioni e le vulnerabilità più importanti, ma isolare tali errori dal flusso generale rappresenta il problema principale. Il numero maggiore di problematiche emergenti è il risultato dell'uso del linguaggio C, che richiede grande attenzione nella gestione della memoria e dei puntatori. La situazione è aggravata dal fatto che molte potenziali correzioni delle vulnerabilità non vengono fornite con identificativi CVE o ricevono tale identificativo solo dopo un certo periodo dalla pubblicazione della correzione. In tali circostanze, per i produttori è molto difficile distinguere le correzioni secondarie dai problemi importanti che influiscono sulla sicurezza. Secondo le statistiche, oltre il 40% delle vulnerabilità viene risolto prima dell'assegnazione del CVE e in media il ritardo tra il rilascio della correzione e l'assegnazione del CVE è di tre mesi (cioè, inizialmente la correzione è percepita come un errore comune, ma solo dopo alcuni mesi diventa chiaro che si tratta di una vulnerabilità risolta).

Di conseguenza, senza un ramo separato per la correzione delle vulnerabilità e senza informazioni sui legami con la sicurezza di un determinato problema, i produttori di prodotti basati sul kernel Linux devono continuamente trasferire tutte le correzioni dalle nuove versioni stabili. Tuttavia, questo lavoro richiede un grande impegno e incontra resistenze nelle aziende a causa della paura di possibili cambiamenti regressivi che potrebbero compromettere il funzionamento normale del prodotto.

Ricordiamo che, secondo Linus Torvalds, tutti gli errori sono importanti e le vulnerabilità non dovrebbero essere separate dagli altri tipi di errori e classificate in una categoria prioritaria a parte. Questa opinione è spiegata dal fatto che per un normale sviluppatore, che non è specializzato in sicurezza, non è evidente il legame tra una correzione e una potenziale vulnerabilità (per molte correzioni, solo un audit separato permette di capire che riguardano la sicurezza). Secondo Linus, le questioni relative all'individuazione delle vulnerabilità potenziali nel flusso generale delle correzioni devono essere trattate dagli specialisti della sicurezza dei team responsabili del supporto dei pacchetti con il kernel nelle distribuzioni Linux.

Kis Kuk ritiene che l'unica soluzione per mantenere la sicurezza del kernel a costi a lungo termine ragionevoli sia la cooperazione tra le aziende di ingegneri impegnati nel porting delle correzioni nelle build locali del kernel. Questa collaborazione dovrebbe mirare alla gestione coordinata delle correzioni e delle vulnerabilità nel kernel principale (upstream). Attualmente, molti produttori utilizzano versioni non aggiornate del kernel nei loro prodotti e retroportano le correzioni autonomamente, il che porta a una duplicazione del lavoro tra gli ingegneri di diverse aziende, che si trovano a risolvere lo stesso problema.

Ad esempio, se 10 aziende, ognuna con un ingegnere che si occupa del backporting delle stesse correzioni, riorientassero questi ingegneri verso la risoluzione di bug nell'upstream, potrebbero invece riparare 10 diversi bug per un beneficio comune, oppure partecipare alla revisione delle modifiche proposte per evitare l'inclusione di codice errato nel kernel. Le risorse potrebbero anche essere reindirizzate alla creazione di nuovi strumenti per il testing e l'analisi del codice, che permetterebbero di identificare automaticamente, in fase precoce, classi ricorrenti di errori che si ripresentano continuamente.

Kees Cook suggerisce di utilizzare in modo più attivo il testing automatizzato e il fuzzing direttamente nel processo di sviluppo del kernel, di implementare sistemi di integrazione continua e di abbandonare la gestione dello sviluppo obsoleta tramite email. Attualmente, l'efficacia del testing è ostacolata dal fatto che i principali processi di testing sono separati dallo sviluppo e avvengono solo dopo la creazione delle versioni. Kees ha anche raccomandato di utilizzare lingue di programmazione che garantiscano maggiore alto livello di sicurezza, come Rust.

Fonte: opennet.ru