Badacze bezpieczeństwa z firmy Cisco szczegóły () w implementacji funkcji memcpy() w Glibc dla 32-bitowej platformy ARMv7. Problem wynika z nieprawidłowego przetwarzania ujemnych wartości parametru definiującego rozmiar kopiowanego obszaru, spowodowanego używaniem optymalizacji assemblerowych, które manipulują liczbami całkowitymi ze znakiem. Wywołanie memcpy() w systemach ARMv7 z ujemnym rozmiarem prowadzi do nieprawidłowego porównania wartości i zapisu poza granicami wskazanego bufora.
Luka ta może być wykorzystana do wykonania kodu w sytuacji, gdy atakujący jest w stanie zorganizować generowanie ujemnej wartości zmiennej, przez którą przekazywany jest rozmiar kopiowanych danych (na przykład, przejście do minus, gdy przekazywane jest więcej niż 2 GB danych, ale w czasie ataku należy przekazać co najmniej 4 GB, aby wyjść poza granice bufora). Funkcja memcpy() jest szeroko stosowana w aplikacjach, a procesory ARMv7 są powszechnie stosowane w systemach samochodowych, mobilnych, przemysłowych, konsumenckich, komunikacyjnych oraz urządzeniach wbudowanych, które mogą stać się przedmiotem ataków z wykorzystaniem Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi i innych zewnętrznych źródeł danych (na przykład, usługi dostępne przez sieć i aplikacje akceptujące dane wejściowe bez ograniczeń rozmiaru mogą być atakowane).
Jako przykład można podać stworzenie działającego exploit'a do ataku na wbudowany w systemy informacyjne samochodu serwer http, dostępny przez sieć Wi-Fi samochodu. Zewnętrzny atakujący może wykorzystać lukę w memcpy w tym serwerze, przesyłając bardzo dużą wartość GET i uzyskać dostęp typu root do systemu.
W 32-bitowych systemach x86 problem nie występuje, ponieważ implementacja memcpy dla tej architektury prawidłowo interpretuje zmienną z rozmiarem jako wartość całkowitą bez znaku typu size_t (w napisanej w assemblerze dla ARMv7 zamiast size_t jest obsługiwana jako liczba całkowita ze znakiem). Poprawka jest na razie dostępna w postaci , która wejdzie w skład sierpniowej aktualizacji Glibc 2.32.
Poprawka polega na zastąpieniu instrukcji assemblerowych operujących na operandach ze znakiem (bge i blt) ich bezpośrednimi odpowiednikami (blo i bhs).
Problem nie został jeszcze rozwiązany w (w Debianie 8 nie występuje), , , OpenEmbedded, Tizen (używa glibc). i problem nie dotyczy, ponieważ nie wspierają 32-bitowych systemów ARMv7. Android nie jest narażony na tę podatność, ponieważ używa własnej implementacji libc (Bionic). W domyślnie w większości wydań używany jest Musl, ale w repozytorium znajduje się także glibc.
Źródło: opennet.ru
