Greg Kroah-Hartman, verantwoordelijk voor het onderhouden van de stabiele tak van de Linux-kernel, besloot de acceptatie van eventuele wijzigingen die van de Universiteit van Minnesota in de Linux-kernel komen te verbieden, en ook om alle eerder geaccepteerde patches terug te draaien en opnieuw te beoordelen. De reden voor de blokkering waren de activiteiten van een onderzoeksgroep die de mogelijkheid bestudeerde om verborgen kwetsbaarheden in de code van open-sourceprojecten te promoten. Deze groep diende patches in die verschillende soorten bugs bevatten, observeerde de reactie van de gemeenschap en bestudeerde manieren om het beoordelingsproces te misleiden voor wijzigingen. Volgens Greg is het uitvoeren van dergelijke experimenten om kwaadaardige veranderingen door te voeren onaanvaardbaar en onethisch.
De reden voor de blokkering was dat de leden van deze groep een patch stuurden die een pointercheck toevoegde om de mogelijke dubbele oproep van de “gratis” functie te elimineren. Gezien de context van het gebruik van de aanwijzer was de controle zinloos. Het doel van het indienen van de patch was om te zien of de foutieve wijziging door de kernelontwikkelaars zou worden beoordeeld. Naast deze patch zijn er nog andere pogingen van ontwikkelaars van de Universiteit van Minnesota opgedoken om dubieuze wijzigingen aan de kernel aan te brengen, inclusief die welke verband houden met de toevoeging van verborgen kwetsbaarheden.
De deelnemer die de patches stuurde, probeerde zichzelf te rechtvaardigen door te zeggen dat hij een nieuwe statische analysator aan het testen was en dat de verandering was voorbereid op basis van de testresultaten daarin. Maar Greg vestigde de aandacht op het feit dat de voorgestelde oplossingen niet typisch zijn voor fouten die door statische analysatoren worden gedetecteerd, en dat alle verzonden patches helemaal niets repareren. Gezien het feit dat de onderzoeksgroep in kwestie in het verleden heeft geprobeerd patches voor verborgen kwetsbaarheden te pushen, is het duidelijk dat ze hun experimenten met de kernelontwikkelingsgemeenschap hebben voortgezet.
Interessant is dat de leider van de groep die de experimenten uitvoerde in het verleden betrokken was bij het legitiem patchen van kwetsbaarheden, bijvoorbeeld door informatielekken in de USB-stack (CVE-2016-4482) en het netwerksubsysteem (CVE-2016-4485) te identificeren. . In een onderzoek naar de verspreiding van stealth-kwetsbaarheden noemt een team van de Universiteit van Minnesota het voorbeeld van CVE-2019-12819, een kwetsbaarheid veroorzaakt door een kernelpatch die in 2014 werd uitgebracht. De oplossing voegde een aanroep naar put_device toe aan het foutafhandelingsblok in mdio_bus, maar vijf jaar later bleek dat een dergelijke manipulatie leidt tot toegang tot het geheugenblok nadat het is vrijgegeven (“use-after-free”).
Tegelijkertijd beweren de auteurs van het onderzoek dat ze in hun werk gegevens hebben samengevat over 138 patches die fouten introduceerden en geen verband hielden met de studiedeelnemers. Pogingen om hun eigen patches met fouten te verzenden bleven beperkt tot e-mailcorrespondentie, en dergelijke wijzigingen kwamen niet in Git terecht (als, na het verzenden van de patch per e-mail, de onderhouder de patch normaal vond, werd hem gevraagd de wijziging niet op te nemen, aangezien er was een fout, waarna ze de juiste patch stuurden).
Toevoeging 1: Afgaande op de activiteit van de auteur van de bekritiseerde patch, stuurt hij al geruime tijd patches naar verschillende kernelsubsystemen. De radeon- en nouveau-stuurprogramma's hebben bijvoorbeeld onlangs wijzigingen aangebracht met een aanroep van pm_runtime_put_autosuspend(dev->dev) in een foutblok, waardoor mogelijk de buffer werd gebruikt nadat het bijbehorende geheugen werd vrijgemaakt.
Addendum 2: Greg heeft 190 commits die verband houden met "@umn.edu" teruggedraaid en een herbeoordeling ervan gestart. Het probleem is dat leden met "@umn.edu"-adressen niet alleen hebben geëxperimenteerd met het pushen van twijfelachtige patches, maar ook echte kwetsbaarheden hebben gepatcht, en het terugdraaien van wijzigingen zou ertoe kunnen leiden dat eerder gepatchte beveiligingsproblemen terugkeren. Sommige beheerders hebben de teruggedraaide wijzigingen al opnieuw gecontroleerd en hebben geen problemen gevonden, maar een van de beheerders gaf aan dat een van de naar hem verzonden patches fouten bevatte.
Bron: opennet.ru