Naukowcy z zespołu Google Project Zero wydani ostatnio za pośrednictwem wpisu na blogu nowa metoda wykorzystywania podatności (CVE-2020-29661) w implementacji obsługi ioctl TIOCSPGRP Podsystem tty jądra Linux, a także szczegółowe mechanizmy ochrony, które mogą blokować te luki.
W poście wspomniano, że problem jest spowodowany błędem w ustawieniach blokady, co prowadzi do sytuacji wyścigu w kodzie /tty/tty_jobctrl.c, który został użyty do stworzenia warunków dostępu do pamięci po uruchomieniu (use-after-free), wykorzystanych przez przestrzeń użytkownika poprzez manipulację za pomocą ioct- poprzez wywołanie TIOCSPGRP.
Oprócz opublikowanych informacji, również wykonano demo funkcjonalnego exploita dla eskalacji uprawnień w Debian 10 z jądrem 4.19.0-13-amd64 co również nie wyklucza, że może mieć wpływ na różne dystrybucje, wśród których są oczywiście te oparte i wywodzące się z Debiana.
Wiele z indywidualnych technik eksploatacji i opcji łagodzenia, które tutaj opisuję, nie jest nowością. Uważam jednak, że warto je spisać, aby pokazać, jak różne łagodzenia współdziałają z dość normalnym exploitem po uwolnieniu.
Fragmenty kodu w tym wpisie na blogu, które dotyczą exploita, pochodzą z poprzedniej wersji 4.19.160, ponieważ na tym jest oparte docelowe jądro Debiana; niektóre inne fragmenty kodu pochodzą z głównej linii Linuksa.
Jednocześnie w opublikowanym artykule nacisk kładziony jest nie tyle na technikę tworzenia funkcjonalnego exploita, co na jakie narzędzia istnieje w jądrze by się chronić przeciwko takim lukom.
Wniosek jest rozczarowujący, jak wspomniano, metody takie jak segmentacja pamięci w stercie i kontrolowanie dostępu do pamięci po jej zwolnieniu nie są stosowane w praktyce, ponieważ prowadzą do obniżenia wydajności i ochrony opartej na CFI (Control Flow Integrity), która blokuje późniejsze exploity etapy ataku, wymaga ulepszeń.
Specjalnym typem urządzenia terminalowego są pseudoterminale, które są używane, gdy na przykład otwierasz aplikację terminalową w środowisku graficznym lub łączysz się ze zdalną maszyną przez SSH. Podczas gdy inne urządzenia terminalowe są podłączone do pewnego rodzaju sprzętu, oba końce pseudoterminalu są kontrolowane przez przestrzeń użytkownika, a pseudoterminale mogą być dowolnie tworzone przez przestrzeń użytkownika (bez uprawnień).
Za każdym razem, gdy otwierany jest /dev/ptmx (skrót od „pseudoterminalny multiplekser”), wynikowy deskryptor pliku reprezentuje stronę urządzenia (określaną w dokumentacji i źródłach jądra jako „główny pseudoterminal”) urządzenia. terminal.
Odpowiednie urządzenie terminalowe (do którego normalnie łączy się powłoka) jest tworzone automatycznie przez jądro w katalogu /dev/pts/ .
Patrząc na to, co może mieć znaczenie na dłuższą metę, nacisk kładzie się na używanie zaawansowanych parserów statycznych lub używanie języków bezpiecznych dla pamięci, takich jak dialekty Rust i C z rozszerzonymi adnotacjami (jak sprawdzone C) do budowania kontrolerów stanu, blokad, obiekty i wskaźniki. Metody ochrony wspominają również o aktywacji trybu panic_on_oops, czyniąc struktury jądra tylko do odczytu i ograniczając dostęp do wywołań systemowych poprzez mechanizmy takie jak seccomp.
Błąd powodujący problem został naprawiony w jądrze Linuksa 3 grudnia zeszłego roku. Problem przejawia się w jądrach przed wersją 5.9.13, ale większość dystrybucji naprawiła problem w aktualizacjach pakietów jądra, które były oferowane w zeszłym roku.
Wspomina się również o podobnej usterce (CVE-2020-29660), która została znaleziona jednocześnie w implementacji wywołania TIOCGSID ioctl, ale została również wszędzie usunięta.
W końcu Jeśli chcesz dowiedzieć się więcej na ten temat, możesz sprawdzić szczegóły W poniższym linku.