I løbet af de sidste par dage har sag om de handlinger, der er truffet af en gruppe forskere fra University of Minnesota, da set fra mange perspektiver har sådanne handlinger i forbindelse med indførelsen af sårbarheder i Linux-kernen ingen begrundelse.
Og selvom en gruppe University of Minnesot Forskereat offentliggøre et åbent undskyldningsbrev, hvis accept af ændringer til Linux-kernen, der blev blokeret af Greg Kroah-Hartman afslørede detaljer af programrettelser sendt til kerneudviklere og korrespondance med vedligeholdere, der er tilknyttet disse programrettelser.
Det er bemærkelsesværdigt, at alle problemrettelser blev afvist På initiativ af vedligeholdere blev ingen af programrettelserne godkendt. Denne kendsgerning gør det klart, hvorfor Greg Kroah-Hartman handlede så hårdt, da det er uklart, hvad forskerne ville have gjort, hvis plasterne var blevet godkendt af vedligeholderen.
Bagefter hævdede, at de havde til hensigt at rapportere fejlen og de tillod ikke pletter at gå til Git, men det er uklart, hvad de rent faktisk ville gøre, eller hvor langt de kunne gå.
I alt i august 2020 blev der sendt fem rettelser fra de anonyme adresser acostag.ubuntu@gmail.com og jameslouisebond@gmail.com (et brev fra James Bond): to korrekte og tre inklusive skjulte fejl, hvilket skabte betingelser for udseendet af sårbarheder.
Hver patch indeholdt kun 1 til 4 linjer kode. Hovedideen bag de dårlige programrettelser var, at reparation af en hukommelseslækage kunne skabe en betingelse for en dobbelt fri sårbarhed.
Projektet sigter mod at forbedre sikkerheden ved patches i OSS. Som en del af projektet studerer vi potentielle problemer med OSS-patches, herunder årsagerne til problemerne og forslag til løsning af dem.
Faktisk afslører denne undersøgelse nogle problemer, men dens mål er at kræve en indsats for at forbedre
patcheringsproces for at motivere mere arbejde til at udvikle teknikker til at teste og verificere programrettelser og endelig for at gøre operativsystemet mere sikkert.Baseret på disse patches opsummerer vi deres mønstre, studerer de specifikke årsager til, at bug introduktionspatches er vanskelige at fange (med både kvalitativ og kvantitativ analyse) og vigtigst af alt giver vi forslag til løsning af problemet.
Den første problematiske patch rettede hukommelseslækagen ved at tilføje et opkald til kfree () inden du returnerer kontrol i tilfælde af en fejl, men skaber betingelser for at få adgang til hukommelsesområdet, efter at det blev frigivet (brug efter-frit).
Den specificerede programrettelse blev afvist af vedligeholderen, der identificerede problemet og antydede, at nogen allerede for et år siden havde forsøgt at foreslå en lignende ændring, og den blev oprindeligt accepteret, men blev kasseret samme dag efter identifikation af sårbarhedsforholdene.
Den anden patch indeholdt også betingelser for slidproblemet efter frigivelse. Den angivne programrettelse blev ikke accepteret af vedligeholderen, der afviste programrettelsen på grund af et andet problem med list_add_tail, men bemærkede ikke, at "chdev" -markøren kan frigives i put_device-funktionen, som bruges næste i opkaldet til dev_err (& chdev -> dev ..). Plasteret blev imidlertid ikke accepteret, omend af årsager, der ikke var relateret til sårbarhed.
Mærkeligt nok oprindeligt blev det antaget, at 4 ud af 5 programrettelser havde problemer, men forskerne selv lavede en fejl og i en problematisk patch blev der efter deres mening foreslået den rigtige løsning uden de formodede betingelser for at bruge hukommelse efter lanceringen.
I dette arbejde præsenterer vi begrebet «umoden sårbarhed», hvor en tilstand af sårbarhed mangler, men det kan blive en reel, når tilstanden implicit er
introduceret af en patch til en anden bug.Vi udvikler også værktøjer, der hjælper os med at finde steder med kode, der kan lide
af fejlintroduktionsopdateringerne og foreslå, hvad der kan gøre disse fejlintroduktionsopdateringer vanskelige at opdage.En uge senere blev information sendt til kerneudviklerne med et forslag om at diskutere muligheden for at promovere sårbarheder under dække af trivielle rettelser til hukommelseslækager, men der blev ikke sagt noget om tidligere forsøg på at indsende ondsindede programrettelser.
Den tredje programrettelse blev også afvist af vedligeholderen på grund af en anden fejl uden sårbarhed (dobbelt applikation i pdev).