Badacze bezpieczeństwa Cisco szczegóły () w implementacji funkcji memcpy() udostępnionej w bibliotece Glibc dla 32-bitowej platformy ARMv7. Problem jest spowodowany nieprawidłową obsługą ujemnych wartości parametru, który określa rozmiar kopiowanego obszaru, ze względu na wykorzystanie optymalizacji asemblera, które operują na 32-bitowych liczbach całkowitych ze znakiem. Wywołanie memcpy() w systemach ARMv7 przy użyciu ujemnego rozmiaru powoduje nieprawidłowe porównania wartości i zapis do obszaru 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, poprzez którą przesyłany jest rozmiar kopiowanych danych (na przykład ujemna wartość wystąpi przy przesyłaniu danych o rozmiarze większym niż 2 GB, ale w trakcie ataku konieczne jest przesłanie co najmniej 4 GB, aby wyjść poza bufor). Funkcja memcpy() jest szeroko stosowana w aplikacjach, a procesory ARMv7 powszechnie występują w systemach motoryzacyjnych, urządzeniach mobilnych, przemysłowych, konsumenckich, komunikacyjnych i wbudowanych, które potencjalnie mogą być atakowane za pomocą Bluetooth, radia HD/DAB, USB, magistrali CAN, Wi-Fi i innych zewnętrznych źródeł danych (na przykład usługi i aplikacje dostępne za pośrednictwem sieci, które akceptują dane wejściowe bez ograniczeń rozmiaru, mogą być atakowane).
Jako przykład podano stworzenie działającego exploita umożliwiającego atak na serwer http wbudowany w systemy informatyczne pojazdów, dostępny poprzez sieć Wi-Fi pojazdów. Zewnętrzny atakujący może wykorzystać lukę w zabezpieczeniach memcpy na tym serwerze, wysyłając bardzo duże żądanie GET i uzyskać dostęp do systemu na poziomie root.
W 32-bitowych systemach x86 problem nie występuje, ponieważ implementacja memcpy dla tej architektury poprawnie interpretuje zmienną o rozmiarze jako wartość całkowitą bez znaku typu size_t (w języku asemblera w przypadku ARMv7 zamiast size_t jest traktowany jako liczba całkowita ze znakiem). Poprawka jest obecnie dostępna jako , która zostanie uwzględniona w sierpniowej aktualizacji Glibc 2.32.
Rozwiązanie problemu polega na zastąpieniu instrukcji asemblera, które działają na operandach ze znakiem (bge i blt) analogami bez znaku (blo i bhs).
Problem nie został jeszcze rozwiązany. (W Debian 8 не проявляется), , , OpenEmbedded, Tizen (używa glibc). и проблема не затрагивает, так как они не поддерживают 32-разрядные системы ARMv7. Android не подвержен уязвимости, так как использует собственную реализацию libc (Bionic). В Domyślnie większość kompilacji używa Musl, ale repozytorium zawiera także glibc.
Źródło: opennet.ru
