Under de senaste dagarna har fall om de åtgärder som vidtagits av en grupp forskare från University of Minnesota, eftersom ur många perspektiv har sådana åtgärder i samband med införandet av sårbarheter i Linux-kärnan ingen motivering.
Och även om en grupp University of Minnesot Forskareatt publicera ett öppet ursäktsbrev, vars godkännande av ändringar av Linux-kärnan som blockerades av Greg Kroah-Hartman, avslöjade detaljer av korrigeringsfiler som skickats till kärnutvecklare och korrespondens med underhållare som är associerade med dessa korrigeringsfiler.
Det är anmärkningsvärt att alla problemkorrigeringar avvisades På initiativ av underhållarna godkändes ingen av lapparna. Detta faktum gör det klart varför Greg Kroah-Hartman agerade så hårt, eftersom det är oklart vad forskarna skulle ha gjort om lapparna hade godkänts av underhållaren.
I efterhand, hävdade att de avsåg att rapportera felet och de tillåter inte lappar att gå till Git, men det är oklart vad de faktiskt skulle göra eller hur långt de kunde gå.
Totalt skickades fem korrigeringar i augusti 2020 från de anonyma adresserna acostag.ubuntu@gmail.com och jameslouisebond@gmail.com (ett brev från James Bond): två korrekta och tre inklusive dolda fel, vilket skapade förutsättningar för utseendet på sårbarheter.
Varje plåster innehöll endast 1 till 4 rader kod. Huvudidén bakom de dåliga korrigeringsfilerna var att fixa en minnesläcka skulle kunna skapa ett villkor för en dubbelfri sårbarhet.
Projektet syftar till att förbättra säkerheten för lappprocessen i OSS. Som en del av projektet studerar vi potentiella problem med OSS-lappprocessen, inklusive orsakerna till problemen och förslag för att ta itu med dem.
I själva verket avslöjar denna studie några problem, men syftet är att kräva ansträngningar för att förbättra
lappprocess för att motivera mer arbete för att utveckla tekniker för att testa och verifiera korrigeringar, och slutligen för att göra operativsystemet säkrare.Baserat på dessa korrigeringar sammanfattar vi deras mönster, studerar de specifika orsakerna till att felintroduktionsplåster är svåra att fånga (med både kvalitativ och kvantitativ analys) och viktigast av allt, ge förslag för att hantera problemet.
Den första problematiska korrigeringen fixade minnesläckan genom att lägga till ett samtal till kfree () innan du återvänder kontrollen vid ett fel, men skapar villkor för att komma åt minnesområdet efter att det har frigjorts (användning efter-fri).
Den angivna korrigeringen avvisades av underhållaren, som identifierade problemet och uppgav att för ett år sedan någon redan hade försökt att föreslå en liknande förändring och den accepterades ursprungligen, men kasserades samma dag efter att ha identifierat sårbarhetsförhållandena.
Den andra plåstret innehöll också villkor för slitage efter utgivningen. Den angivna korrigeringen accepterades inte av underhållaren, som avvisade korrigeringen på grund av ett annat problem med list_add_tail, men märkte inte att "chdev" -pekaren kan frigöras i funktionen put_device, som används nästa i samtalet till dev_err (& chdev -> dev ..). Plåstret accepterades dock inte, om än av skäl som inte är relaterade till sårbarhet.
Nyfiket, ursprungligen antogs att fyra av fem lappar hade problem, men forskarna själva gjorde ett misstag och i en problematisk patch föreslogs enligt deras uppfattning den rätta lösningen utan de förmodade villkoren för att använda minne efter lanseringen.
I detta arbete presenterar vi begreppet «omogen sårbarhet» där ett sårbarhetsvillkor saknas, men det kan bli ett verkligt när tillståndet är
introduceras av en patch för en annan bug.Vi utvecklar också verktyg som hjälper oss att hitta platser med kod som kan drabbas
av felintroduktionsplåstren och föreslå vad som kan göra dessa felintroduktionsplåster svåra att upptäcka.En vecka senare skickades information till kärnutvecklarna med ett förslag för att diskutera möjligheten att främja sårbarheter under sken av triviala korrigeringar för minnesläckor, men ingenting sades om tidigare försök att skicka skadliga korrigeringar.
Den tredje korrigeringen avvisades också av underhållaren på grund av ett annat fel utan sårbarhet (dubbel applikation i pdev).