De Universiteit van Minnesota wordt verboden om opzettelijk buggy-patches in Linux-kernel te testen

Dankzij de Solarwinds inbreuk op de beveiliging , software supply chain-aanvallen zijn een belangrijk punt geworden. Er wordt natuurlijk veel onderzoek gedaan naar deze aanvallen. Twee afgestudeerde studenten aan de Universiteit van Minnesota die aan een paper werkten met de titel ” On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits ” probeerden de Use-After-Free (UAF) kwetsbaarheid in de Linux-kernel te stoppen . Dit soort Red Team-beveiligingstests is alledaags… wanneer het project mensen omvat die van tevoren weten wat er aan de hand is. Dat was hier niet het geval. Toen ze het opnieuw probeerden, had Greg Kroah-Hartman, de Linux-kernelonderhouder voor de stabiele tak, er genoeg van.

In de Linux Kernel Mailing List (LKML) maakte Kroah-Hartman dit nog duidelijker toen ze opnieuw probeerden een nep-patch te introduceren. “Als je naar de code kijkt, is dit onmogelijk gebeurd [red]. Stop alsjeblieft met het indienen van bekende ongeldige patches. Je professor speelt wat rond met het beoordelingsproces om op een vreemde en bizarre manier tot een paper te komen. Dit is niet oké, het is tijdverspilling, en we zullen dit OPNIEUW aan je universiteit moeten melden … ”

Je zou kunnen denken dat deze afgestudeerde studenten de hint zouden kunnen begrijpen. Ze deden het niet. Een van de onderzoekers, Aditya Pakki, dubbelde. Pakki stuurde Kroah-Hartman een bericht waarin hij zei: “Ik vraag u respectvol te stoppen en af ​​te zien van het uiten van wilde beschuldigingen die aan laster grenzen.” Hij beweerde ook dat deze patches het resultaat waren van een nieuwe statische analysator die hij had geschreven. Pakki sloot af: “Ik zal geen patches meer sturen vanwege de houding die niet alleen onwelkom is, maar ook intimiderend voor nieuwkomers en niet-experts.”

Kroah-Hartman had er genoeg van. Hij antwoorde:

Jij en je groep hebben publiekelijk toegegeven dat je patches met bekende bugs hebt gestuurd om te zien hoe de kernelgemeenschap erop zou reageren en publiceerde een paper gebaseerd op dat werk.

Nu dien je weer een nieuwe reeks duidelijk incorrecte patches in, dus wat moet ik van zoiets denken?

Ze waren duidelijk _NIET_ gemaakt door een statisch analyse-instrument dat van enige intelligentie is, aangezien ze allemaal het resultaat zijn van totaal verschillende patronen en die duidelijk helemaal niets oplossen. Dus wat moet ik hier denken, anders dan dat jij en je groep doorgaan met experimenteren op de ontwikkelaars van de kernelgemeenschap door zulke onzinpatches te sturen?

Bij het indienen van patches die door een tool zijn gemaakt, dient iedereen die dat doet ze in met bewoordingen als “gevonden door tool XXX, we weten niet zeker of dit correct is of niet, geef dit alstublieft aan.” wat je hier helemaal NIET hebt gedaan. Je vroeg niet om hulp, je beweerde dat dit legitieme oplossingen waren, waarvan je WIST dat ze onjuist waren.

Een paar minuten met iemand met de schijn van kennis van C kan zien dat uw inzendingen helemaal niets doen, dus denken dat een tool ze heeft gemaakt en vervolgens dat u dacht dat ze een geldige ‘fix’ waren, is totaal nalatig op uw deel, niet het onze. Jij bent degene die schuldig is, het is niet onze taak om de proefpersonen te zijn van een tool die je maakt.

Onze community verwelkomt ontwikkelaars die Linux willen helpen en verbeteren. Dat is NIET wat u hier probeert te doen, dus probeer het alsjeblieft niet op die manier te kaderen.

Onze gemeenschap stelt het niet op prijs om op geëxperimenteerd te worden en om “getest” te worden door bekende patches in te dienen die ofwel met opzet niets doen of met opzet bugs introduceren. Als je dit soort werk wilt doen, raad ik je aan een andere gemeenschap te zoeken om je experimenten op uit te voeren, je bent hier niet welkom.

Deze ontwikkelaars komen niet meer terug. En omdat de Universiteit van Minnesota ze niet tegenhield nadat ze waren gewaarschuwd, raakte Kroah-Hartman de hele school met de grootste club in het Linux-kernelarsenaal: “Ik zal nu alle toekomstige bijdragen van je universiteit moeten bannen en je eerdere bijdragen, aangezien ze duidelijk te kwader trouw waren ingediend met de bedoeling problemen te veroorzaken. ”

De meeste Linux-kernelontwikkelaars en andere programmeurs zijn het met Kroah-Hartman eens. Ted T’so, een senior Linux-kernelontwikkelaar en Google-engineer, merkt op dat hoewel de professor die verantwoordelijk is voor dit project, Kangjie Lu, in het verleden nuttig beveiligingswerk heeft verricht:
Het probleem is dat Prof. Lu en zijn team geen berouw lijken te hebben , en een aantal zeer … scheve … ideeën hebben over wat als ethisch en acceptabel gedrag wordt beschouwd ten opzichte van de ontwikkelingsgemeenschap van Kernel. Het feit dat het UMN IRB [Institutional Review Board] -team van mening is dat wat Prof. Lu doet niet wordt beschouwd als ruimte voor menselijke experimenten, betekent dat er bij UMN geen enkele vorm van institutionele controle is voor dit soort gedrag – wat Daarom is een universitaire ban misschien wel het enige juiste antwoord.

Red Hat Technology Strateeg, Jered Floyd, ging verder in zijn tweet: ” Dit is erger dan alleen geëxperimenteerd te worden ; dit is alsof je zegt dat je een ‘veiligheidsonderzoeker’ bent door naar een supermarkt te gaan en de remleidingen op alle auto’s om te zien hoeveel mensen crashen als ze vertrekken. Enorm onethisch. ”

De onderzoekers beweren in hun paper dat geen van hun patches ooit in een Linux-coderepository is terechtgekomen, dat ze alleen in een e-mail verschenen in plaats van een Git-commit te worden voor een Linux-kerneltak. Dat is niet het geval.

Romanovsky meldde dat hij had gekeken naar vier geaccepteerd patches van Pakki “en 3 van hen toegevoegd verschillende ernst security ‘gaten’.” Sudip Mukherjee, Linux kernel driver en Debian -ontwikkelaar, opgevolgd en zei “veel van deze zijn reeds de stabiele bereikt bomen. ”Deze patches worden nu verwijderd.

Dus deze “onderzoekers” verspilden niet alleen de tijd van Linux-committers, maar ze introduceerden in feite slechte code in de Linux-kernel. Hierna denk ik dat ik gerust kan zeggen dat geen van hen ooit welkom zal zijn in de Linux-kernel of enig ander open-sourceproject in de toekomst.