Wczoraj Ujawniono informację o luce w jądrze Linuksa i który jest już skatalogowany jako CVE-2021-3609. Ta luka pozwala lokalnemu użytkownikowi podnieść swoje uprawnienia w systemie z powodu wyścigu w implementacji protokołu CAN BCM i objawia się w wersjach jądra Linuksa od 2.6.25 do 5.13-rc6.
Porażka wykorzystuje ponieważ Protokół CAN BCM umożliwia zarejestrowanie własnego menedżera komunikatów sieci kontrolera (CAN) i podłącz go do dedykowanego gniazda sieciowego. Gdy nadejdzie wiadomość przychodząca, funkcja jest wywoływana bcm_rx_handler() atakujący może wykorzystać sytuację wyścigu i wymusić zamknięcie gniazda sieciowego w tym samym czasie co wykonanie bcm_rx_handler().
Problem pojawia się, gdy gniazdo jest zamknięte i funkcja jest wywoływana bcm_release(), w którym zostaje zwolniona pamięć przydzielona strukturom bcm_op i bcm_sock, które nadal są używane w programie obsługi bcm_rx_handler() która wciąż działa, powstaje więc sytuacja, która prowadzi do dostępu do już zwolnionego bloku pamięci (use-after-free).
To jest zapowiedź niedawno zgłoszonego błędu (CVE-2021-3609) w protokole sieciowym CAN BCM w jądrze Linuksa od wersji 2.6.25 do mainline 5.13-rc6.
Luka jest stanem wyścigu w net/can/bcm.c, który umożliwia eskalację uprawnień do roota. Problem został początkowo zgłoszony przez syzbota, a Norbert Slusarek okazał się możliwy do wykorzystania.
Atak sprowadza się do otwarcia dwóch gniazd CAN BCM i powiązania ich z interfejsem vcan. W pierwszym łączniku dzwonisz wyślij wiadomość () ze wskaźnikiem RX_SETUP skonfigurować sterownik na przychodzące komunikaty CAN i na drugim gnieździe zadzwonić wyślij wiadomość () aby wysłać wiadomość do pierwszego łącznika.
Po nadejściu wiadomości wywoływane jest wywołanie bcm_rx_handler(), a atakujący wykorzystuje odpowiedni moment i zamyka pierwsze gniazdo, co prowadzi do uwolnienia bcm_release() i uruchomienie konstrukcji bcm_op i bcm_sock, chociaż praca bcm_rx_handler() nie została jeszcze zakończona.
Manipulując zawartością bcm_sock, osoba atakująca może nadpisać wskaźnik do funkcji sk-> sk_data_ready (sk), przekierować wykonanie i za pomocą technik programowania zorientowanego na zwrot (ROP) nadpisać parametr modprobe_path i spowodować awarię kodu. uruchom jako root.
Gdy używana jest technika ROP, atakujący nie próbuje umieścić swojego kodu ku pamięci, ale działa dalej kawałki instrukcji obsługi maszyny, które są już dostępne w załadowanych bibliotekach, zakończone instrukcją control return (z reguły są to końcówki funkcji bibliotecznych).
Uprawnienia niezbędne do przeprowadzenia ataku może uzyskać nieuprzywilejowany użytkownik w kontenerach utworzonych na systemach z włączonymi przestrzeniami nazw użytkowników. Na przykład przestrzenie nazw użytkowników są domyślnie uwzględniane w Ubuntu i Fedorze, ale nie są włączone w Debianie i RHEL.
Moja próba wykorzystania exploitów koncentruje się na jądrach w wersji >= 5.4-rc1 od czasu zatwierdzenia bf74aa86e111. Nie zastanawiałem się nad wykorzystywaniem jąder starszych niż 5.4-rc1 przy użyciu taskletów, jednak wykorzystywanie starszych jąder również wydaje się wykonalne.
Wspomina się, że badacz, który zidentyfikował lukę, był w stanie przygotować exploit w celu uzyskania uprawnień roota na systemach z jądrami od wersji 5.4 i nowszych, w tym możliwość udanego ataku na Ubuntu 20.04.02 LTS.
Działanie exploita sprowadza się do zbudowania łańcucha wywołań podobnych bloków („gadżetów”) w celu uzyskania wymaganej funkcjonalności. Atak wymaga dostępu do tworzenia gniazd CAN oraz skonfigurowanego interfejsu sieciowego vcan.
W końcu wspomina się, że problem nadal występuje w większości dystrybucji, ale to kwestia dni, zanim odpowiednie łatki zostaną wydane.
Jeśli chcesz dowiedzieć się więcej na ten temat, możesz się skonsultować poniższy link.