I løpet av de siste dagene har sak om handlingene som er tatt av en gruppe forskere fra University of Minnesota, siden slike perspektiver i forhold til innføring av sårbarheter i Linux-kjernen, fra mange, ikke har noen begrunnelse.
Og selv om en gruppe University of Minnesot Forskereå publisere et åpent unnskyldningsbrev, hvis aksept av endringer i Linux-kjernen som ble blokkert av Greg Kroah-Hartman, avslørte detaljer av oppdateringer sendt til kjerneutviklere og korrespondanse med vedlikeholdere tilknyttet disse oppdateringene.
Det er bemerkelsesverdig at alle problemoppdateringer ble avvist På initiativ fra vedlikeholdspersonene ble ingen av lappene godkjent. Dette faktum gjør det klart hvorfor Greg Kroah-Hartman handlet så hardt, ettersom det er uklart hva forskerne ville ha gjort hvis lappene hadde blitt godkjent av vedlikeholderen.
I ettertid, hevdet at de hadde til hensikt å rapportere feilen og de tillot ikke lapper å gå til Git, men det er uklart hva de faktisk vil gjøre eller hvor langt de kan gå.
Totalt ble det i august 2020 sendt fem oppdateringer fra de anonyme adressene acostag.ubuntu@gmail.com og jameslouisebond@gmail.com (et brev fra James Bond): to riktige og tre inkludert skjulte feil, noe som skaper betingelser for utseendet til sårbarheter.
Hver oppdatering inneholdt bare 1 til 4 linjer med kode. Hovedideen bak de dårlige oppdateringene var at å fikse en minnelekkasje kunne skape en betingelse for et dobbelt gratis sårbarhet.
Prosjektet har som mål å forbedre sikkerheten ved oppdateringsprosessen i OSS. Som en del av prosjektet studerer vi potensielle problemer med OSS-oppdateringsprosessen, inkludert årsakene til problemene og forslag til å løse dem.
Faktisk avslører denne studien noen problemer, men målet er å kreve innsats for å forbedre
lappeprosess for å motivere mer arbeid for å utvikle teknikker for å teste og verifisere oppdateringer, og til slutt for å gjøre operativsystemet sikrere.Basert på disse oppdateringene oppsummerer vi mønstrene deres, studerer de spesifikke årsakene til at feilintroduksjonsoppdateringer er vanskelig å fange (med både kvalitativ og kvantitativ analyse), og viktigst av alt gir vi forslag for å løse problemet.
Den første problematiske oppdateringen fikset minnelekkasjen ved å legge til en samtale til kfree () før du returnerer kontrollen i tilfelle en feil, men skaper betingelser for å få tilgang til minneområdet etter at det ble frigjort (bruk etter-fri).
Den spesifiserte oppdateringen ble avvist av vedlikeholderen, som identifiserte problemet og antydet at noen for et år siden allerede hadde prøvd å foreslå en lignende endring, og den ble opprinnelig akseptert, men kastet samme dag etter å ha identifisert sårbarhetsforholdene.
Den andre lappen inneholdt også betingelser for slitasje etter frigjøring. Den spesifiserte oppdateringen ble ikke godtatt av vedlikeholderen, som avviste oppdateringen på grunn av et annet problem med list_add_tail, men la ikke merke til at "chdev" -pekeren kan frigjøres i put_device-funksjonen, som brukes neste i samtalen til dev_err (& chdev -> dev ..). Imidlertid ble lappen ikke akseptert, om enn av årsaker som ikke var relatert til sårbarhet.
Merkelig nok opprinnelig ble det antatt at 4 av 5 lapper hadde problemer, men forskerne selv gjorde en feil og i en problematisk oppdatering ble det etter deres mening foreslått den riktige løsningen uten de antatte forholdene for å bruke minne etter lansering.
I dette arbeidet presenterer vi begrepet «umoden sårbarhet» der en tilstand av sårbarhet mangler, men det kan bli en reell når tilstanden implisitt er
introdusert av en lapp for en annen feil.Vi utvikler også verktøy som hjelper oss med å finne steder med kode som kan lide
av feilintroduksjonsoppdateringene og foreslå hva som kan gjøre disse feilintroduksjonsoppdateringene vanskelig å oppdage.En uke senere ble informasjon sendt til kerneutviklerne med et forslag om å diskutere muligheten for å fremme sårbarheter under dekke av trivielle rettelser for minnelekkasjer, men ingenting ble sagt om tidligere forsøk på å sende inn ondsinnede oppdateringer.
Den tredje oppdateringen ble også avvist av vedlikeholderen på grunn av en annen feil uten sårbarhet (dobbel applikasjon i pdev).