Luki w jądrze Linuksa wykorzystywane zdalnie poprzez Bluetooth

W jądrze Linuksa zidentyfikowano lukę (CVE-2022-42896), która potencjalnie może zostać wykorzystana do zorganizowania zdalnego wykonania kodu na poziomie jądra poprzez przesłanie specjalnie zaprojektowanego pakietu L2CAP przez Bluetooth. Ponadto zidentyfikowano inny podobny problem (CVE-2022-42895) w procedurze obsługi L2CAP, który może prowadzić do wycieku zawartości pamięci jądra w pakietach z informacjami konfiguracyjnymi. Pierwsza podatność pojawia się od sierpnia 2014 r. (jądro 3.16), druga zaś od października 2011 r. (jądro 3.0). Luki zostały usunięte w wersjach jądra Linuksa 6.1.0, 6.0.8, 4.9.333, 4.14.299, 4.19.265, 5.4.224, 5.10.154 i 5.15.78. Poprawki w dystrybucjach możesz śledzić na stronach: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.

Aby zademonstrować możliwość przeprowadzenia zdalnego ataku, opublikowano prototypowe exploity działające na Ubuntu 22.04. Aby przeprowadzić atak, atakujący musi znajdować się w zasięgu Bluetooth — wstępne parowanie nie jest wymagane, ale Bluetooth musi być aktywny w komputerze. Do ataku wystarczy znajomość adresu MAC urządzenia ofiary, który można ustalić poprzez wąchanie lub, w przypadku niektórych urządzeń, obliczony na podstawie adresu MAC Wi-Fi.

Pierwsza podatność (CVE-2022-42896) spowodowana jest dostępem do już zwolnionego obszaru pamięci (use-after-free) w realizacji funkcji l2cap_connect i l2cap_le_connect_req - po utworzeniu kanału poprzez wywołanie zwrotne new_connection nie została ustawiona blokada dla niego, ale ustawiono timer (__set_chan_timer ), po upływie limitu czasu wywołanie funkcji l2cap_chan_timeout i wyczyszczenie kanału bez sprawdzania zakończenia pracy z kanałem w funkcjach l2cap_le_connect*.

Domyślny timeout wynosi 40 sekund i zakładano, że z takim opóźnieniem nie może dojść do sytuacji wyścigu, okazało się jednak, że w wyniku innego błędu w obsłudze SMP udało się uzyskać natychmiastowe wywołanie timera i uzyskać warunki wyścigu. Problem w l2cap_le_connect_req może prowadzić do wycieku pamięci jądra, a w l2cap_connect może prowadzić do nadpisania zawartości pamięci i wykonania jej kodu. Pierwszy rodzaj ataku można przeprowadzić z wykorzystaniem Bluetooth LE 4.0 (od 2009 r.), drugi przy wykorzystaniu Bluetooth BR/EDR 5.2 (od 2020 r.).

Druga podatność (CVE-2022-42895) jest spowodowana wyciekiem pamięci resztkowej w funkcji l2cap_parse_conf_req, która może zostać wykorzystana do zdalnego uzyskania informacji o wskaźnikach do struktur jądra poprzez wysyłanie specjalnie spreparowanych żądań konfiguracyjnych. Funkcja l2cap_parse_conf_req wykorzystywała strukturę l2cap_conf_efs, dla której przydzielona pamięć nie była preinicjowana i manipulując flagą FLAG_EFS_ENABLE możliwe było włączenie do pakietu starych danych ze stosu. Problem pojawia się tylko w systemach, w których jądro jest zbudowane z opcją CONFIG_BT_HS (domyślnie wyłączona, ale włączona w niektórych dystrybucjach, takich jak Ubuntu). Udany atak wymaga również ustawienia parametru HCI_HS_ENABLED za pośrednictwem interfejsu zarządzania na wartość true (domyślnie nieużywany).

Źródło: opennet.ru

Dodaj komentarz