W ciągu ostatnich kilku dni przypadku działań podjętych przez grupę badaczy z University of Minnesota, gdyż z perspektywy wielu takie działania w związku z wprowadzaniem luk w jądrze Linuksa nie mają uzasadnienia.
I chociaż grupa University of Minnesot Researchersopublikować otwarty list z przeprosinami, których akceptacja zmian w jądrze Linuksa została zablokowana przez Greg Kroah-Hartman ujawnił szczegóły poprawek przesłanych do programistów jądra i korespondencji z opiekunami związanymi z tymi łatkami.
Warto zauważyć, że wszystkie poprawki problemów zostały odrzucone Z inicjatywy opiekunów żadna z łat nie została zatwierdzona. Fakt ten wyjaśnia, dlaczego Greg Kroah-Hartman zachował się tak surowo, ponieważ nie jest jasne, co zrobiliby badacze, gdyby łaty zostały zatwierdzone przez opiekuna.
Z perspektywy czasu argumentowali, że zamierzali zgłosić błąd i nie pozwoliliby łatkom na przejście do Git, ale nie jest jasne, co faktycznie zrobią ani jak daleko mogą się posunąć.
W sumie w sierpniu 2020 roku z anonimowych adresów acostag.ubuntu@gmail.com i jameslouisebond@gmail.com (list od Jamesa Bonda) wysłano pięć łatek: dwie poprawne i trzy zawierające ukryte błędy, stwarzające warunki do pojawienia się luki w zabezpieczeniach.
Każda łatka zawierała tylko od 1 do 4 linii kodu. Główną ideą stojącą za złymi łatami było to, że naprawienie wycieku pamięci może stworzyć warunek podwójnego zwolnienia luki w zabezpieczeniach.
Projekt ma na celu poprawę bezpieczeństwa procesu patchowania w OSS. W ramach projektu badamy potencjalne problemy związane z procesem patchowania OSS, w tym przyczyny problemów i sugestie ich rozwiązania.
W rzeczywistości to badanie ujawnia pewne problemy, ale jego celem jest wezwanie do podjęcia wysiłków w celu ulepszenia
proces poprawiania poprawek, aby zmotywować więcej pracy do opracowania technik testowania i weryfikowania poprawek, a wreszcie do zwiększenia bezpieczeństwa systemu operacyjnego.Na podstawie tych poprawek podsumowujemy ich wzorce, badamy konkretne powody, dla których łaty wprowadzające błędy są trudne do wyłapania (zarówno z analizą jakościową, jak i ilościową), a co najważniejsze, przedstawiamy sugestie dotyczące rozwiązania problemu.
Pierwsza problematyczna łatka naprawiła wyciek pamięci, dodając wywołanie do kfree () przed zwróceniem kontroli w przypadku błędu, ale tworzenie warunków dostępu do obszaru pamięci po jego zwolnieniu (użyj po zwolnieniu).
Podana poprawka została odrzucona przez opiekuna, który zidentyfikował problem i wskazał, że rok temu ktoś już próbował zaproponować podobną zmianę i została ona wstępnie zaakceptowana, ale tego samego dnia po zidentyfikowaniu warunków podatności została odrzucona.
Druga łatka zawierała również warunki dotyczące kwestii zużycia po wydaniu. Podana łata nie została zaakceptowana przez opiekuna, który odrzucił ją z powodu innego problemu z list_add_tail, ale nie zauważył, że wskaźnik "chdev" może zostać zwolniony w funkcji put_device, która jest następnie używana w wywołaniu dev_err (& chdev -> dev ..). Jednak łatka nie została zaakceptowana, choć z powodów niezwiązanych z podatnością.
Ciekawie, początkowo zakładano, że 4 z 5 łatek ma problemy, ale sami badacze popełnili błąd i ich zdaniem w problematycznej łatce zaproponowano poprawne rozwiązanie, bez rzekomych warunków korzystania z pamięci po uruchomieniu.
W tej pracy przedstawiamy pojęcie „niedojrzałej podatności”, w przypadku której brak jest warunku podatności, ale może stać się prawdziwym, gdy stan jest niejawnie
wprowadzone przez poprawkę dla innego błędu.Tworzymy również narzędzia, które pomagają nam znaleźć miejsca kodu, które mogą ucierpieć
poprawek wprowadzających błędy i zasugeruj, co może utrudniać ich wykrycie.Tydzień później do twórców jądra przesłano informacje z propozycją omówienia możliwości promowania luk w zabezpieczeniach pod pozorem trywialnych poprawek wycieków pamięci, ale nie powiedziano nic o wcześniejszych próbach przesyłania złośliwych łat.
Trzecia łatka została również odrzucona przez opiekuna z powodu innego błędu bez podatności (podwójna aplikacja w pdev).