Pytaj listę, nie pole: nasz use-after-free w kernelu Linuksa

Tym razem to nasze. Fuzzing kodu, który przechowuje skojarzenia bezpieczeństwa IPsec, wykrył use-after-free. Napisaliśmy poprawkę i dziś jest ona w każdej utrzymywanej gałęzi stable Linuksa. Piszemy o tym, bo kształt tego błędu jest bardziej pouczający niż sam crash.

Pytanie, które zadawał kod

Kiedy kernel usuwa stan IPsec, musi zdjąć obiekt z czterech list haszujących. Przy dwóch z nich kod decydował o zdjęciu na podstawie wartości: czy stan ma numer sekwencyjny, czy ma SPI. To zastępnik pytania, które naprawdę ma znaczenie: czy obiekt w ogóle jest na liście.

Zwykle zastępnik i prawda się zgadzają. Przy współbieżności potrafią się rozjechać, a wtedy ścieżka usuwania albo pomija zdjęcie z listy, którego potrzebowała, albo wykonuje takie, którego nie powinna. Drugie usunięcie tego samego obiektu pisze wtedy przez wskaźnik zatruty za pierwszym razem. Ta sama funkcja zadawała już właściwe pytanie przy dwóch nowszych listach. Starszych nikt nie wyrównał.

przed:
if (x->km.seq)
        hlist_del_rcu(&x->byseq);
if (x->id.spi)
        hlist_del_rcu(&x->byspi);

po:
if (!hlist_unhashed(&x->byseq))
        hlist_del_init_rcu(&x->byseq);
if (!hlist_unhashed(&x->byspi))
        hlist_del_init_rcu(&x->byspi);

Dwie zmiany i każda robi co innego. Pytanie listy zamiast pola sprawia, że decyzja śledzi rzeczywistość. Ponowna inicjalizacja węzła przy usuwaniu sprawia, że drugie usunięcie jest nieszkodliwym no-opem, a nie zapisem przez zatruty wskaźnik.

Pole to deklaracja o stanie

To ten sam błąd, o którym ciągle piszemy przy systemach agentowych, tylko warstwę niżej. Pole mówiące, że obiekt ma SPI, to deklaracja o tym, gdzie obiekt jest. Lista to fakt. Kod, który ufa deklaracji, działa, dopóki coś nie zmieni jednego bez drugiego, a współbieżność jest dokładnie tym czymś.

Agent, który ufa opisowi narzędzia zamiast temu, co narzędzie robi. Kontrola uprawnień, która ufa etykiecie zamiast zasobowi. Ścieżka usuwania, która ufa liczbie zamiast liście. Różne warstwy, jeden nawyk. Zaufanie to powierzchnia ataku, także zaufanie, jakim funkcja darzy własną księgowość.

Czego poprawka celowo nie robi

Nie tropi jednego konkretnego przeplotu, który zwalnia obiekt dwa razy. Sprawia, że usuwanie jest idempotentne, a warunek prawdziwy, więc skutek znika niezależnie od tego, która ścieżka dotrze pierwsza. Maintainerzy przyjęli ją właśnie na takich warunkach. Łatka na ten jeden wyścig, który akurat złapaliśmy, byłaby węższa i zostawiłaby miejsce następnemu.

Część, która nigdy nie trafia do CVE

Pierwsza wersja się nie nakładała. Poszła przez webowego klienta poczty, który wyciął z diffa wszystkie tabulatory, i nie miała tagu Fixes:. Maintainer poprosił o tag, opiekun gałęzi stable odpisał listem szablonowym z odnośnikiem do zasad stable, a ponowna wysyłka przez git send-email została przyjęta następnego ranka.

Ten tag to nie formalność. To mechanizm, który przenosi poprawkę do starszych gałęzi. Bez niego łatka wylądowałaby w mainline i na tym by się skończyło. Każda poprawka dalej w łańcuchu, wymieniona w kronice, istnieje dlatego, że jedna linia wskazała commity, które wprowadziły błąd.

Gdzie kończy błąd w kernelu

Crash znaleziony na maszynach wirtualnych w chmurze trafia do advisory przemysłowego sterownika i do długoterminowych kerneli korporacyjnych, które większość ludzi uważa za zamrożone. Dla firmy, która kupuje sprzęt, wniosek jest praktyczny: Twoja ekspozycja to nie wersja Twojego kernela. To każde urządzenie z Linuksem, którego nie budowałeś, łatane w rytmie dostawcy, a nie upstreamu.

Co zrobić

• Przejdź na pierwsze wydanie ze swojej gałęzi stable, które ma poprawkę. Kronika je wymienia. Gałęzie długoterminowe dostały ją tygodnie po mainline, więc sprawdź, zamiast zakładać.
• Jeśli nie możesz jeszcze łatać, przyjrzyj się nieuprzywilejowanym przestrzeniom nazw użytkownika. Niska ocena wymaganych uprawnień opiera się właśnie na nich. Hosty, które ich nie potrzebują, tracą tę ścieżkę.
• Zapytaj dostawców urządzeń, na jakim są etapie. Sterowniki, firewalle i macierze działają na kernelach, których nie widzisz. Jeden dostawca przemysłowy oznaczył to jako podatne i nie ma jeszcze poprawionego firmware.
• Jeśli przeglądasz kod kernela lub systemowy, szukaj warunków-zastępników. Każdy warunek, który sprawdza wartość zamiast przynależności, własności czy stanu, warto zastąpić sprawdzeniem samej rzeczy.