Negli ultimi giorni il caso sulle azioni intraprese da un gruppo di ricercatori dall'Università del Minnesota, poiché dal punto di vista di molti, tali azioni in relazione all'introduzione di vulnerabilità nel kernel Linux non hanno giustificazione.
E anche se un gruppo Ricercatori dell'Università del Minnesotpubblicare una lettera di scuse aperta, la cui accettazione delle modifiche al kernel Linux che è stata bloccata da Greg Kroah-Hartman, ha rivelato i dettagli di patch inviate agli sviluppatori del kernel e corrispondenza con i manutentori associati a queste patch.
E 'degno di nota tutte le patch problematiche sono state rifiutate Su iniziativa dei manutentori, nessuna delle patch è stata approvata. Questo fatto rende chiaro perché Greg Kroah-Hartman abbia agito in modo così duro, poiché non è chiaro cosa avrebbero fatto i ricercatori se le patch fossero state approvate dal manutentore.
Ripensandoci, ha sostenuto che intendevano segnalare il bug e non consentirebbero alle patch di andare a Git, ma non è chiaro cosa farebbero effettivamente o fino a che punto potrebbero spingersi.
In totale, nell'agosto 2020, cinque patch sono state inviate dagli indirizzi anonimi acostag.ubuntu@gmail.com e jameslouisebond@gmail.com (una lettera di James Bond): due corrette e tre includendo errori nascosti, creando le condizioni per la comparsa di vulnerabilità.
Ogni patch conteneva solo da 1 a 4 righe di codice. L'idea principale alla base delle patch errate era che la correzione di una perdita di memoria potrebbe creare una condizione per una doppia vulnerabilità libera.
Il progetto mira a migliorare la sicurezza del processo di patching in OSS. Come parte del progetto, studiamo potenziali problemi con il processo di patching OSS, comprese le cause dei problemi e suggerimenti per risolverli.
In effetti, questo studio rivela alcuni problemi, ma il suo scopo è richiedere sforzi per migliorare il
processo di patching per motivare più lavoro allo sviluppo di tecniche per testare e verificare le patch e, infine, per rendere il sistema operativo più sicuro.Sulla base di queste patch, riassumiamo i loro modelli, studiamo i motivi specifici per cui le patch di introduzione di bug sono difficili da individuare (con analisi sia qualitativa che quantitativa) e, soprattutto, forniamo suggerimenti per affrontare il problema.
La prima patch problematica ha risolto la perdita di memoria aggiungendo una chiamata a kfree () prima di restituire il controllo in caso di errore, ma creando le condizioni per accedere all'area di memoria dopo che è stata liberata (use-after-free).
La patch specificata è stata rifiutata dal manutentore, che ha individuato il problema e indicato che un anno fa qualcuno aveva già provato a proporre una modifica simile ed è stata inizialmente accettata, ma scartata lo stesso giorno dopo aver individuato le condizioni di vulnerabilità.
La seconda patch conteneva anche le condizioni per il problema di usura post-rilascio. La patch specificata non è stata accettata dal manutentore, che l'ha rifiutata a causa di un altro problema con list_add_tail, ma non ha notato che il puntatore "chdev" può essere liberato nella funzione put_device, che viene usata successivamente nella chiamata a dev_err (& chdev -> dev ..). Tuttavia, la patch non è stata accettata, anche se per motivi estranei alla vulnerabilità.
Curiosamente, inizialmente si presumeva che 4 patch su 5 avessero problemi, ma gli stessi ricercatori hanno commesso un errore e in una patch problematica, a loro avviso, è stata proposta la soluzione corretta, senza le presunte condizioni per utilizzare la memoria dopo il lancio.
In questo lavoro, presentiamo il concetto di "vulnerabilità immatura" in cui manca una condizione di vulnerabilità, ma può diventare reale quando la condizione è
introdotto da una patch per un altro bug.Sviluppiamo anche strumenti che ci aiutano a trovare luoghi di codice che potrebbero risentirne
delle patch di introduzione dei bug e suggeriscono cosa potrebbe rendere queste patch di introduzione dei bug difficili da rilevare.Una settimana dopo, le informazioni sono state inviate agli sviluppatori del kernel con una proposta per discutere la possibilità di promuovere le vulnerabilità sotto le spoglie di banali correzioni per perdite di memoria, ma non è stato detto nulla sui precedenti tentativi di inviare patch dannose.
Anche la terza patch è stata rifiutata dal manutentore a causa di un altro bug senza vulnerabilità (doppia applicazione in pdev).