Badacze bezpieczeństwa Cisco szczegóły () w implementacji funkcji memcpy() dostarczonej przez Glibc dla 32-bitowej platformy ARMv7. Problem wynika z nieprawidłowej obsługi wartości ujemnych parametru określającego rozmiar kopiowanego obszaru, w związku ze stosowaniem optymalizacji asemblera manipulujących 32-bitowymi liczbami całkowitymi ze znakiem. Wywołanie memcpy() na systemach ARMv7 z rozmiarem ujemnym skutkuje niepoprawnym porównaniem wartości i zapisem w obszarze poza granicami określonego bufora.
Lukę można wykorzystać do wykonania kodu w sytuacji, gdy atakujący może zorganizować utworzenie ujemnej wartości zmiennej, przez którą przesyłany jest rozmiar kopiowanych danych (przykładowo będzie ona ujemna przy przesyłaniu więcej niż 2 GB danych, ale w trakcie ataku, aby przekroczyć limity bufora, trzeba przesłać co najmniej 4 GB). Funkcja memcpy() jest szeroko stosowana w aplikacjach, a procesory ARMv7 są powszechnie stosowane w systemach motoryzacyjnych, urządzeniach mobilnych, przemysłowych, konsumenckich, komunikacyjnych i wbudowanych, które są potencjalnie podatne na ataki z wykorzystaniem Bluetooth, HD Radio/DAB, USB, magistrali CAN, Wi-Fi Fi i inne zewnętrzne źródła danych (na przykład usługi i aplikacje dostępne w sieci, które akceptują dane wejściowe bez ograniczeń rozmiaru, mogą zostać zaatakowane).
Przykładem jest stworzenie działającego exploita atakującego serwer HTTP wbudowany w samochodowe systemy informacyjne, dostępny za pośrednictwem samochodowej sieci Wi-Fi. Osoba atakująca z zewnątrz może wykorzystać lukę w zabezpieczeniach memcpy na tym serwerze, wysyłając bardzo duże żądanie GET i uzyskując dostęp roota do systemu.
W 32-bitowych systemach x86 problem nie pojawia się, ponieważ implementacja memcpy dla tej architektury poprawnie interpretuje zmienną size jako wartość całkowitą bez znaku typu size_t (w języku asemblera dla ARMv7 jest ona traktowana jako liczba całkowita ze znakiem zamiast size_t). Poprawka jest obecnie dostępna jako , które zostaną uwzględnione w sierpniowej aktualizacji Glibc 2.32.
Poprawka sprowadza się do zastąpienia stosowania instrukcji asemblera operujących na operandach ze znakiem (bge i blt) ich odpowiednikami bez znaku (blo i bhs).
Problem nie został jeszcze rozwiązany (niewidoczne w Debianie 8), , , OpenEmbedded, Tizen (używany przez glibc). и Problem nie dotyczy, ponieważ nie obsługują one 32-bitowych systemów ARMv7. Luka nie dotyczy systemu Android, ponieważ korzysta z własnej implementacji biblioteki libc (Bionic). W Domyślnie większość kompilacji używa Musl, ale glibc jest również dostępny w repozytorium.
Źródło: opennet.ru