În ultimele zile caz asupra acțiunilor întreprinse de un grup de cercetători de la Universitatea din Minnesota, deoarece din perspectiva multora, astfel de acțiuni în legătură cu introducerea vulnerabilităților în nucleul Linux nu au nicio justificare.
Și chiar dacă un grup Cercetătorii Universității din Minnesotasă publice o scrisoare deschisă de scuze, a cărui acceptare a modificărilor aduse nucleului Linux blocat de Greg Kroah-Hartman a dezvăluit detalii de patch-uri trimise dezvoltatorilor de kernel și corespondență cu mentenanții asociați cu aceste patch-uri.
Este de remarcat faptul că toate patch-urile cu probleme au fost respinse La inițiativa întreținătorilor, niciunul dintre patch-uri nu a fost aprobat. Acest fapt arată clar de ce Greg Kroah-Hartman a acționat atât de aspru, deoarece nu este clar ce ar fi făcut cercetătorii dacă patch-urile ar fi fost aprobate de către întreținător.
În retrospectivă, a susținut că intenționează să raporteze eroarea și nu ar permite ca patch-urile să meargă la Git, dar nu este clar ce ar face de fapt sau cât de departe ar putea merge.
În total, în august 2020, au fost trimise cinci patch-uri de la adresele anonime acostag.ubuntu@gmail.com și jameslouisebond@gmail.com (o scrisoare de la James Bond): două corecte și trei, inclusiv erori ascunse, creând condiții pentru apariția vulnerabilități.
Fiecare patch conținea doar 1 până la 4 linii de cod. Ideea principală din spatele patch-urilor proaste a fost că remedierea unei scurgeri de memorie ar putea crea o condiție pentru o vulnerabilitate dublă gratuită.
Proiectul își propune să îmbunătățească securitatea procesului de corecție în OSS. Ca parte a proiectului, studiem potențiale probleme cu procesul de corecție OSS, inclusiv cauzele problemelor și sugestii pentru soluționarea acestora.
De fapt, acest studiu relevă unele probleme, dar scopul său este de a cere eforturi pentru a îmbunătăți
proces de corecție pentru a motiva mai multă muncă pentru a dezvolta tehnici de testare și verificare a corecțiilor și, în cele din urmă, pentru a face sistemul de operare mai sigur.Pe baza acestor patch-uri, le rezumăm modelele, studiem motivele specifice pentru care patch-urile de introducere a erorilor sunt dificil de prins (cu analize atât calitative cât și cantitative) și, cel mai important, oferim sugestii pentru soluționarea problemei.
Primul patch problematic a rezolvat scurgerea de memorie adăugând un apel la kfree () înainte de a returna controlul în caz de eroare, dar de a crea condiții pentru a accesa zona de memorie după ce a fost eliberată (use-after-free).
Patch-ul specificat a fost respins de către întreținător, care a identificat problema și a indicat că în urmă cu un an cineva a încercat deja să propună o schimbare similară și a fost inițial acceptată, dar aruncată în aceeași zi după identificarea condițiilor de vulnerabilitate.
Al doilea plasture conținea, de asemenea, condiții pentru problema uzurii după eliberare. Patch-ul specificat nu a fost acceptat de către întreținător, care a respins patch-ul din cauza unei alte probleme cu list_add_tail, dar nu a observat că indicatorul „chdev” poate fi eliberat în funcția put_device, care este utilizată în continuare în apelul către dev_err (& chdev -> dev ..). Cu toate acestea, patch-ul nu a fost acceptat, deși din motive care nu au legătură cu vulnerabilitatea.
Cu interes, inițial s-a presupus că 4 din 5 patch-uri au avut probleme, dar cercetătorii înșiși au făcut o greșeală și într-un patch problematic, în opinia lor, a fost propusă soluția corectă, fără condițiile presupuse de a utiliza memoria după lansare.
În această lucrare, prezentăm conceptul de „vulnerabilitate imatură” în care lipsește o condiție de vulnerabilitate, dar poate deveni una reală atunci când condiția este implicit
introdus de un patch pentru o altă eroare.De asemenea, dezvoltăm instrumente care ne ajută să găsim locuri de cod care ar putea suferi
dintre patch-urile de introducere a erorilor și sugerează ce ar putea face aceste patch-uri de introducere a erorilor dificil de detectat.O săptămână mai târziu, informațiile au fost trimise dezvoltatorilor de kernel cu o propunere de a discuta despre posibilitatea promovării vulnerabilităților sub masca unor remedieri banale pentru scurgerile de memorie, dar nu s-a spus nimic despre încercările anterioare de a trimite patch-uri rău intenționate.
Cel de-al treilea patch a fost respins, de asemenea, de către întreținător din cauza unei alte erori fără vulnerabilitate (dublă aplicație în pdev).