Twórcy mobilnego systemu operacyjnego Aurora (widelec Sailfish OS opracowanego przez firmę Open Mobile Platform) podzielili się odkrywczą historią dotyczącą eliminacji () w Glibc, który pojawia się tylko na platformie ARMv7. Informacje o luce ujawniono już w maju, jednak do niedawna nie były dostępne żadne poprawki, mimo że luki wysoki poziom zagrożenia i istnieje działający prototyp exploita, który pozwala zorganizować wykonanie kodu podczas przetwarzania danych sformatowanych w określony sposób w funkcjach memcpy() i memmove(). Poprawki pakietu dla и nie zostały jeszcze opublikowane, a luka pozostaje nienaprawiona przez prawie dwa miesiące od momentu publicznego ujawnienia i pięć miesięcy od momentu powiadomienia twórców Glibc.
Luka objawiała się implementacją memcpy() i memmove() w języku asemblera dla ARMv7 i była spowodowana nieprawidłowym przetwarzaniem ujemnych wartości parametru określającego wielkość kopiowanego obszaru. Problemy z rozwojem łatek zaczęły się, gdy firmy и ogłosili, że problem nie dotyczy ich platform, ponieważ nie tworzą oprogramowania dla 32-bitowych systemów ARMv7 i nie uczestniczyli w tworzeniu poprawki. Wydaje się, że twórcy wielu dystrybucji osadzonych polegali na zespole Glibc i nie byli aktywnie zaangażowani w przygotowanie poprawki.
Opcja Aby zablokować problem, Huawei niemal natychmiast zaproponował próbę zastąpienia instrukcji asemblera operujących operandami ze znakiem (bge i blt) analogami bez znaku (blo i bhs). Opiekunowie Glibc opracowali zestaw testów sprawdzających różne warunki błędów, po czym okazywało się, że łatka Huawei nie była odpowiednia i nie przetwarzała wszystkich możliwych kombinacji danych wejściowych.
Ponieważ Aurora OS ma 32-bitową wersję dla ARM, jej twórcy postanowili samodzielnie zamknąć lukę i zaoferować rozwiązanie społeczności. Trudność polegała na tym, że konieczne było napisanie wydajnej implementacji funkcji w języku asemblerowym i uwzględnienie różnych opcji argumentów wejściowych. Implementacja została przepisana przy użyciu niepodpisanych instrukcji. Okazało się, że jest niewielki, ale głównym problemem było utrzymanie szybkości wykonywania i uniknięcie pogorszenia wydajności funkcji memcpy i memmove, przy jednoczesnym zachowaniu kompatybilności ze wszystkimi kombinacjami wartości wejściowych.
Na początku czerwca przygotowano dwie wersje poprawki, która przeszła pomyślnie środowisko testowe opiekunów Glibc oraz wewnętrzny zestaw testów Aurory. 3 czerwca wybrano jedną z opcji i na listę mailingową Glibc. Tydzień później
było kolejna łatka o podobnym podejściu, która naprawiła problem w implementacji multiarch, który Huawei próbował wcześniej naprawić. Testowanie trwało miesiąc i ze względu na znaczenie poprawki.
Korekty z 8 lipca do głównej gałęzi nadchodzącej wersji glibc 2.32. Implementacja obejmuje dwie poprawki − do wieloarchicznej implementacji memcpy dla ARMv7 i do implementacji memcpy() i memmove() w języku asemblera dla ARM.
Problem dotyczy milionów urządzeń ARMv7 z systemem Linux i bez odpowiedniej aktualizacji właściciele są narażeni na ryzyko podczas podłączania ich do sieci (mogą zostać zaatakowane usługi i aplikacje dostępne w sieci, które akceptują dane wejściowe bez ograniczeń rozmiaru). Na przykład exploit przygotowany przez badaczy, którzy zidentyfikowali lukę, pokazuje, jak zaatakować serwer HTTP wbudowany w samochodowy system informacji, wysyłając bardzo duże żądanie GET i uzyskując dostęp roota do systemu.
Źródło: opennet.ru