De afgelopen dagen heeft het case over de acties van een groep onderzoekers van de Universiteit van Minnesota, aangezien vanuit het perspectief van velen dergelijke acties met betrekking tot de introductie van kwetsbaarheden in de Linux Kernel geen rechtvaardiging hebben.
En ook al is het een groep Onderzoekers van de Universiteit van Minnesotaom een open verontschuldigingsbrief te publiceren, wiens acceptatie van wijzigingen aan de Linux-kernel die werd geblokkeerd door Greg Kroah-Hartman, onthulde details van patches die zijn ingediend bij kernelontwikkelaars en correspondentie met beheerders die aan deze patches zijn gekoppeld.
het is opmerkelijk dat alle probleempatches werden afgewezen Op initiatief van de beheerders werd geen van de patches goedgekeurd. Dit feit maakt duidelijk waarom Greg Kroah-Hartman zo hard handelde, aangezien het onduidelijk is wat de onderzoekers zouden hebben gedaan als de patches waren goedgekeurd door de onderhouder.
Achteraf bezien voerde aan dat ze van plan waren de bug te rapporteren en ze stonden niet toe dat patches naar Git gingen, maar het is onduidelijk wat ze werkelijk zouden doen of hoe ver ze zouden kunnen gaan.
In totaal werden in augustus 2020 vijf patches verzonden vanaf de anonieme adressen acostag.ubuntu@gmail.com en jameslouisebond@gmail.com (een brief van James Bond): twee correcte en drie inclusief verborgen fouten, waardoor voorwaarden werden gecreëerd voor het verschijnen van kwetsbaarheden.
Elke patch bevatte slechts 1 tot 4 regels code. Het belangrijkste idee achter de slechte patches was dat het verhelpen van een geheugenlek een voorwaarde zou kunnen zijn voor een dubbele gratis kwetsbaarheid.
Het project heeft tot doel de beveiliging van het patchproces in OSS te verbeteren. Als onderdeel van het project bestuderen we mogelijke problemen met het OSS-patchproces, inclusief de oorzaken van de problemen en suggesties om ze aan te pakken.
In feite brengt deze studie enkele problemen aan het licht, maar het doel is om inspanningen te vragen om de
patchproces om meer werk te motiveren om technieken te ontwikkelen om patches te testen en te verifiëren, en ten slotte om het besturingssysteem veiliger te maken.Op basis van deze patches vatten we hun patronen samen, bestuderen we de specifieke redenen waarom patches voor het introduceren van bugs moeilijk te vangen zijn (met zowel kwalitatieve als kwantitatieve analyse), en, belangrijker nog, geven we suggesties om het probleem aan te pakken.
De eerste problematische patch repareerde het geheugenlek door een aanroep toe te voegen aan kfree() voordat de controle wordt teruggegeven in het geval van een fout, maar voorwaarden worden gecreëerd om toegang te krijgen tot het geheugengebied nadat het is vrijgegeven (use-after-free).
De opgegeven patch is afgewezen door de onderhouder, die het probleem identificeerde en aangaf dat iemand een jaar geleden al had geprobeerd een soortgelijke wijziging voor te stellen en deze aanvankelijk werd geaccepteerd, maar dezelfde dag werd weggegooid nadat de kwetsbaarheidscondities waren geïdentificeerd.
De tweede patch bevatte ook voorwaarden voor het gebruiksprobleem na de release.. De gespecificeerde patch werd niet geaccepteerd door de onderhouder, die de patch afwees vanwege een ander probleem met list_add_tail, maar merkte niet dat de "chdev" -aanwijzer kan worden vrijgemaakt in de put_device-functie, die vervolgens wordt gebruikt in de aanroep van dev_err (& chdev -> dev ..). De patch werd echter niet geaccepteerd, zij het om redenen die geen verband hielden met de kwetsbaarheid.
Vreemd genoeg, aanvankelijk werd aangenomen dat 4 van de 5 patches problemen hadden, maar de onderzoekers maakten zelf een fout en in een problematische patch werd naar hun mening de juiste oplossing voorgesteld, zonder de veronderstelde voorwaarden om geheugen na de lancering te gebruiken.
In dit werk presenteren we het concept van "onvolwassen kwetsbaarheid" waarbij een voorwaarde van kwetsbaarheid ontbreekt, maar het kan een reële worden wanneer de voorwaarde is
geïntroduceerd door een patch voor een andere bug.We ontwikkelen ook tools die ons helpen plaatsen in de code te vinden die eronder lijden
van de bugintroductie-patches en suggereren wat deze bug-introductiepatches moeilijk te detecteren zou kunnen maken.Een week later werd informatie naar de kernelontwikkelaars gestuurd met een voorstel om de mogelijkheid te bespreken om kwetsbaarheden te promoten onder het mom van triviale oplossingen voor geheugenlekken, maar er werd niets gezegd over eerdere pogingen om kwaadaardige patches in te dienen.
De derde patch werd ook afgewezen door de onderhouder vanwege een andere bug zonder kwetsbaarheid (dubbele applicatie in pdev).