Kees Cook, ex CSO di kernel.org e leader dell'Ubuntu Security Team, che ora lavora per Google per proteggere Android e ChromeOS, ha espresso preoccupazione per l'attuale processo di correzione dei bug nei rami stabili del kernel. Ogni settimana, circa un centinaio di correzioni vengono incluse nei rami stabili, e dopo aver chiuso la finestra per accettare le modifiche al rilascio successivo, si avvicina a mille (i manutentori mantengono le correzioni finché la finestra non viene chiusa, e dopo la formazione di "-rc1" pubblicare subito quelli accumulati), che è troppo e richiede molto lavoro per la manutenzione dei prodotti basati sul kernel Linux.
Secondo Keys, al processo di gestione degli errori nel kernel non viene prestata la dovuta attenzione e al kernel mancano almeno altri 100 sviluppatori aggiuntivi per un lavoro coordinato in quest'area. Gli sviluppatori del kernel principale risolvono i bug regolarmente, ma non vi è alcuna garanzia che queste correzioni vengano trasferite alle varianti del kernel utilizzate da terze parti. Inoltre, gli utenti di vari prodotti basati sul kernel Linux non hanno modo di controllare quali bug vengono corretti e quale kernel viene utilizzato nei loro dispositivi. I fornitori sono in ultima analisi responsabili della sicurezza dei loro prodotti, ma con un tasso di applicazione di patch molto elevato nei rami stabili del kernel, si sono trovati di fronte alla scelta tra eseguire il backport di tutte le patch, eseguire il porting selettivo delle più importanti o ignorare tutte le patch.
La soluzione ottimale sarebbe quella di migrare solo le correzioni e le vulnerabilità più importanti, ma isolare tali errori dal flusso generale è il problema principale. La maggior parte dei problemi che si presentano sono dovuti all'uso del linguaggio C, che richiede molta attenzione quando si ha a che fare con memoria e puntatori. A peggiorare le cose, molte potenziali correzioni di vulnerabilità non vengono fornite con identificatori CVE o ricevono tale identificatore qualche tempo dopo la pubblicazione della patch. In tali condizioni, è molto difficile per i produttori distinguere le soluzioni minori dai problemi di sicurezza più importanti. Secondo le statistiche, più del 40% delle vulnerabilità vengono risolte prima che venga assegnata una CVE e il ritardo medio tra il rilascio di una patch e l’assegnazione di una CVE è di tre mesi (vale a dire, all’inizio, la patch viene percepita come un problema comune) bug, ma solo dopo qualche mese diventa chiaro che la vulnerabilità è stata risolta).
Di conseguenza, senza avere un ramo separato con correzioni per le vulnerabilità e senza ricevere informazioni sulla connessione di sicurezza di un particolare problema, i produttori di prodotti basati sul kernel Linux sono costretti a trasferire continuamente tutte le correzioni da nuovi rami stabili. Ma questo lavoro richiede molto lavoro e incontra resistenza nelle aziende a causa del timore di cambiamenti regressivi che potrebbero interrompere 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 assegnate a una categoria separata con priorità più alta. Questa opinione è spiegata dal fatto che per uno sviluppatore ordinario che non è specializzato in questioni di sicurezza, la connessione tra una correzione e una potenziale vulnerabilità non è ovvia (per molte correzioni, solo un audit separato consente di capire che si riferiscono alla sicurezza ). Secondo Linus, spetta ai team di sicurezza responsabili della manutenzione dei pacchetti del kernel sulle distribuzioni Linux isolare le potenziali vulnerabilità dal flusso generale delle patch.
Kees Cook ritiene che l'unica soluzione per mantenere il kernel sicuro a un costo ragionevole a lungo termine sia che le aziende spostino gli ingegneri coinvolti nel porting delle patch sulle build del kernel locale affinché lavorino in modo collaborativo e coordinato per mantenere le patch e le vulnerabilità nel kernel upstream. Nella sua forma attuale, molti produttori non utilizzano la versione più recente del kernel nei loro prodotti e correggono autonomamente il backport, ad es. si scopre che gli ingegneri di aziende diverse duplicano il lavoro degli altri, risolvendo lo stesso problema.
Ad esempio, se 10 aziende, ciascuna con un tecnico che supporta le stesse correzioni, reindirizzassero tali tecnici per correggere i bug a monte, invece di trasferire una correzione, potrebbero correggere 10 bug diversi per il bene comune o partecipare alla revisione delle modifiche proposte. impedire che il codice difettoso venga incluso nel kernel. Le risorse potrebbero anche essere dedicate alla creazione di nuovi strumenti per il test e l'analisi del codice, che consentirebbero in una fase iniziale di identificare automaticamente le tipiche classi di errori che si ripresentano ripetutamente.
Kees Cook suggerisce inoltre un uso più attivo di test automatizzati e fuzzing direttamente nel processo di sviluppo principale, l'uso di sistemi di integrazione continua e l'abbandono dell'arcaica gestione dello sviluppo via e-mail. Attualmente, l'efficacia dei test è ostacolata dal fatto che i principali processi di test sono separati dallo sviluppo e avvengono dopo la formazione dei rilasci. Keys consiglia inoltre di utilizzare linguaggi più sicuri, come Rust, per ridurre i bug.
Fonte: opennet.ru