Počas posledných dní prípade akcií skupiny výskumných pracovníkov z univerzity v Minnesote, pretože z pohľadu mnohých takéto akcie súvisiace so zavedením zraniteľností v jadre Linuxu nemajú žiadne opodstatnenie.
A to aj napriek tomu, že skupina University of Minnesot Researcherszverejniť otvorený ospravedlňujúci list, ktorých prijatie zmien v jadre Linuxu bolo zablokované Greg Kroah-Hartman prezradil podrobnosti opráv odoslaných vývojárom jadra a korešpondencia s správcami spojenými s týmito opravami.
Je pozoruhodné, že všetky problémové opravy boli zamietnuté Na podnet správcov nebola schválená žiadna z náplastí. Táto skutočnosť objasňuje, prečo Greg Kroah-Hartman postupoval tak tvrdo, pretože nie je jasné, čo by vedci urobili, keby opravy schválil správca.
V spätnom pohľade, argumentovali tým, že majú v úmysle nahlásiť chybu a nedovolili by opravám ísť na Git, ale nie je jasné, čo by vlastne urobili alebo ako ďaleko by mohli zájsť.
Celkovo bolo v auguste 2020 zaslaných päť opráv z anonymných adries acostag.ubuntu@gmail.com a jameslouisebond@gmail.com (list od Jamesa Bonda): dve správne a tri vrátane skrytých chýb, čo vytvára podmienky pre výskyt zraniteľnosti.
Každá oprava obsahovala iba 1 až 4 riadky kódu. Hlavnou myšlienkou chybných opráv bolo, že oprava úniku pamäte by mohla vytvoriť podmienku pre dvojnásobnú bezplatnú zraniteľnosť.
Cieľom projektu je zvýšiť bezpečnosť procesu opráv v OSS. V rámci projektu študujeme potenciálne problémy s procesom opravy OSS, vrátane príčin problémov a návrhov na ich riešenie.
Táto štúdia v skutočnosti odhaľuje určité problémy, jej cieľom je však vyzvať na úsilie o zlepšenie
proces opráv, ktorý motivuje viac práce k vývoju techník na testovanie a overovanie opráv a nakoniec k zvýšeniu bezpečnosti OS.Na základe týchto opráv zhrnieme ich vzorce, preštudujeme konkrétne dôvody, prečo sa záplaty na zavedenie chýb ťažko zachytia (kvalitatívnou aj kvantitatívnou analýzou), a čo je najdôležitejšie, poskytneme návrhy na riešenie problému.
Prvá problematická oprava opravila únik pamäte pridaním volania na kfree () pred vrátením ovládacieho prvku v prípade chyby, ale vytváranie podmienok pre prístup do oblasti pamäte po jej uvoľnení (use-after-free).
Zadanú opravu správca odmietol, ktorý identifikoval problém a naznačil, že pred rokom sa už niekto pokúsil navrhnúť podobnú zmenu a tá bola pôvodne prijatá, ale v rovnaký deň po identifikácii podmienok zraniteľnosti zahodená.
Druhá oprava obsahovala aj podmienky týkajúce sa problému s opotrebením po vydaní. Zadanú opravu neprijal správca, ktorý opravu odmietol z dôvodu iného problému s list_add_tail, ale nevšimol si, že ukazovateľ „chdev“ je možné uvoľniť vo funkcii put_device, ktorá sa použije vo výzve dev_err (& chdev -> dev ..). Oprava však nebola prijatá, aj keď z dôvodov nesúvisiacich so zraniteľnosťou.
Kuriózne je, pôvodne sa predpokladalo, že 4 z 5 opráv mali problémy, ale samotní vedci urobili chybu a v problémovej aktualizácii bolo podľa ich názoru navrhnuté správne riešenie bez predpokladaných podmienok na použitie pamäte po štarte.
V tejto práci uvádzame koncept «nezrelej zraniteľnosti» tam, kde podmienka zraniteľnosti chýba, ale môže sa stať skutočnou, ak je podmienka implicitne
zavedená záplatou pre ďalšiu chybu.Vyvíjame tiež nástroje, ktoré nám pomáhajú nájsť miesta kódu, ktoré môžu trpieť
aktualizácií opráv na zavedenie chyby a navrhnite, čo by mohlo sťažiť odhalenie týchto opráv na zavedenie chyby.O týždeň neskôr boli vývojárom jadra zaslané informácie s návrhom diskutovať o možnosti podpory zraniteľností pod zámienkou triviálnych opráv pre úniky pamäte, ale o predchádzajúcich pokusoch o odoslanie škodlivých opráv sa nehovorilo nič.
Tretiu opravu správca odmietol aj kvôli ďalšej chybe bez zraniteľnosti (dvojitá aplikácia v pdev).