Kees cucinare Faccio un post sul blog in cui ha sollevato preoccupazioni sul processo di correzione dei bug in corso nei rami stabili del kernel Linux ed è così menziona che settimana per settimana sono incluse circa un centinaio di correzioni su rami stabili, che è troppo e richiede un grande sforzo per mantenere i prodotti basati su kernel Linux.
Secondo Kees, il processo di gestione degli errori del kernel viene bypassato e al kernel mancano almeno 100 sviluppatori aggiuntivi lavorare in modo coordinato in questo settore. Oltre a menzionare che i principali sviluppatori del kernel risolvono regolarmente i bug, ma non vi è alcuna garanzia che queste correzioni vengano trasferite a varianti del kernel di terze parti.
In tal modo, afferma che gli utenti di vari prodotti basati su kernel Linux non hanno modo di controllare quali bug vengono corretti e quale kernel viene utilizzato sui loro dispositivi. In definitiva, i fornitori sono responsabili della sicurezza dei loro prodotti, ma di fronte a un tasso molto elevato di patch sui rami del kernel stabili, si sono trovati di fronte alla scelta di migrare tutte le patch, migrare selettivamente quelle più importanti o ignorare tutte le patch. .
Gli sviluppatori del kernel a monte possono correggere i bug, ma non hanno alcun controllo su ciò che un fornitore a valle sceglie di incorporare nei loro prodotti. Gli utenti finali possono scegliere i loro prodotti, ma generalmente non hanno alcun controllo su quali bug vengono corretti o quale kernel viene utilizzato (un problema in sé e per sé). In definitiva, i fornitori sono responsabili della sicurezza dei core dei loro prodotti.
Kees cucinare suggerisce che la soluzione ottimale sarebbe trasferire solo le correzioni e le vulnerabilità più importanti, ma il problema principale è separare questi errori dal flusso generale, poiché la maggior parte dei problemi emergenti sono una conseguenza dell'uso del linguaggio C, che richiede molta attenzione quando si lavora con memoria e puntatori.
A peggiorare le cose, molte potenziali correzioni di vulnerabilità non sono contrassegnate con identificatori CVE o non ricevono un identificatore CVE qualche tempo dopo il rilascio della patch.
In un ambiente del genere, è molto difficile per i produttori separare le correzioni minori dai principali problemi di sicurezza. Secondo le statistiche, più del 40% delle vulnerabilità vengono rimosse prima dell'assegnazione CVE, e in media il ritardo tra un rilascio di fix e un'assegnazione CVE è di tre mesi (cioè, all'inizio, si percepisce una soluzione come un errore comune,
Di conseguenza, non avere un ramo separato con correzioni per le vulnerabilità e non ricevere informazioni sulla connessione con la sicurezza di questo o quel problema, i produttori di prodotti basati su kernel Linux devono trasferire continuamente tutte le correzioni delle nuove filiali stabili. Ma questo lavoro è ad alta intensità di lavoro e incontra la resistenza delle aziende a causa dei timori di cambiamenti regressivi che potrebbero interrompere il normale funzionamento del prodotto.
Cuoco chiavi ritiene che l'unica soluzione per mantenere il kernel sicuro a un costo ragionevole a lungo termine sia trasferire i tecnici delle patch alle folli build del kernell lavorare insieme in modo coordinato per mantenere patch e vulnerabilità nel kernel upstream. Così com'è, molti fornitori non usano le ultime versioni del kernel nei loro prodotti e le correzioni di backport da soli, cioè, si scopre che gli ingegneri di diverse aziende duplicano il lavoro degli altri, risolvendo lo stesso problema.
Ad esempio, se 10 aziende, ognuna con un tecnico che supporta le stesse correzioni, reindirizzano questi ingegneri per correggere i bug a monte, invece di migrare una correzione, potrebbero correggere 10 bug diversi per il beneficio complessivo o riunirsi per rivedere i bug. . Ed evita di includere codice difettoso nel kernel. Le risorse potrebbero anche essere utilizzate per creare nuovi strumenti di analisi e test del codice che rileverebbero automaticamente in una fase iniziale le tipiche classi di errore che si verificano più e più volte.
Cuoco chiavi propone inoltre di utilizzare più attivamente test e fuzzing automatizzati direttamente nel processo di sviluppo del kernel, utilizzare sistemi di integrazione continua e abbandonare la gestione arcaica dello sviluppo tramite e-mail.
fonte: https://security.googleblog.com