Критична вразливість у реалізації функції memcpy для ARMv7 зі складу Glibc

Дослідники безпеки з компанії Cisco розкрили деталі уразливості (CVE-2020-6096) у реалізації функції, що надається в Glibc memcpy() для 32-розрядної платформи ARMv7. Проблема викликана некоректною обробкою негативних значень параметра, що визначає розмір копіюється області, через використання асемблерних оптимізації, що маніпулюють знаковими 32-розрядними цілими числами. Виклик memcpy() на системах ARMv7 з негативним розміром призводить до некоректного порівняння значень та запису в області поза межами зазначеного буфера.

Вразливість може бути експлуатована для виконання коду в ситуації, коли атакуючий може організувати формування негативного значення змінної, через яку передається розмір даних, що копіюються (наприклад, догляд в мінус буде при передачі більше 2 ГБ даних, але в процесі атаки для виходу за межі буфера потрібно передати як мінімум 4ГБ). Функція memcpy() активно застосовується в додатках, а процесори ARMv7 поширені в автомобільних системах, мобільних, промислових, споживчих, комунікаційних та вбудованих пристроях, які потенційно можуть стати об'єктами атак з використанням Bluetooth, HD Radio/DAB, USB, CAN bus, Wi- Fi та інших зовнішніх джерел даних (наприклад, можуть бути атаковані доступні по мережі сервіси та програми, що приймають вхідні дані без обмеження розміру).

Як приклад наводиться створення робочого експлоїту для атаки на вбудований автомобільні інформаційні системи http-сервер, доступний через автомобільну Wi-Fi мережу. Сторонній атакуючий може експлуатувати вразливість у memcpy на даному сервері через передачу GET-запиту дуже великого розміру та отримати root-доступ до системи.

Критична вразливість у реалізації функції memcpy для ARMv7 зі складу Glibc

На 32-розрядних системах x86 проблема не проявляється, так як реалізація memcpy для даної архітектури коректно інтерпретує змінну з розміром як ціле беззнакове значення з типом size_t (в написаній на асемблері реалізації для ARMv7 замість size_t воно обробляється як signed integer). Виправлення поки що доступне у вигляді патча, що увійде до складу серпневого оновлення Glibc 2.32.
Виправлення зводиться до заміни використання асемблерних інструкцій, що оперують знаковими операндами (bge та blt), на беззнакові аналоги (blo та bhs).

Проблема поки не усунена в Debian 9 та 10 (Debian 8 не проявляється), Fedora, Ubuntu, OpenEmbedded, Tizen (використовується glibc). RHEL и SUSE проблема не торкається, оскільки вони не підтримують 32-розрядні системи ARMv7. Android не схильний до вразливості, тому що використовує власну реалізацію libc (Bionic). У OpenWRT за замовчуванням у більшості збірок використовується Musl, але репозиторії є і glibc.

Джерело: opennet.ru

Додати коментар або відгук