Suicide
22.05.2020, 21:53
Исследователи безопасности из компании Cisco раскрыли (https://blog.talosintelligence.com/2020/05/cve-2020-6096.html) детали уязвимости (https://talosintelligence.com/vulnerability_reports/TALOS-2020-1019) (CVE-2020-6096 (https://security-tracker.debian.org/tracker/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-доступ к системе.
https://www.opennet.ru/opennews/pics_base/0_1590093329.png (https://1.bp.blogspot.com/-jn5Ehvf41zM/XsaUrrbL_OI/AAAAAAAABtE/naydd40WyaApbJtZWKMokafBH7--HTNNQCLcBGAsYHQ/s1600/image20.png)
На 32-разрядных системах x86 проблема не проявляется, так как реализация memcpy для данной архитектуры корректно интерпретирует переменную с размером как беззнаковое целое значение с типом size_t (в написанной на ассемблере реализации (https://code.woboq.org/userspace/glibc/sysdeps/arm/memcpy.S.html) для ARMv7 вместо size_t оно обрабатывается как signed integer). Исправление пока доступно в виде патча (https://patchwork.sourceware.org/project/glibc/patch/ac494a6febda4430857df1fc31f64e19@huawei.com/), который войдёт в состав августовском обновлении Glibc 2.32. Исправление сводится к замене использования ассемблерных инструкций, оперирующих знаковыми операндами (bge и blt), на беззнаковые аналоги (blo и bhs).
Проблема пока не устранена в Debian 9 и 10 (https://security-tracker.debian.org/tracker/CVE-2020-6096) (в Debian 8 не проявляется), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1820332), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-6096.html), OpenEmbedded, Tizen (используется glibc). RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-6096) и SUSE (https://bugzilla.suse.com/show_bug.cgi?id=CVE-2020-6096) проблема не затрагивает, так как они не поддерживают 32-разрядные системы ARMv7. Android не подвержен уязвимости, так как использует собственную реализацию libc (Bionic). В OpenWRT (https://openwrt.org/advisory/start) по умолчанию в большинстве сборок используется Musl, но в репозитории имеется и glibc.
21.05.2020
https://www.opennet.ru/opennews/art.shtml?num=53003
Уязвимость может быть эксплуатирована для выполнения кода в ситуации, когда атакующий может организовать формирование отрицательного значения переменной, через которую передаётся размер копируемых данных (например, уход в минус будет при передаче более 2 ГБ данных, но в процессе атаки для выхода за пределы буфера нужно передать как минимум 4ГБ). Функция memcpy() активно применяется в приложениях, а процессоры ARMv7 распространены в автомобильных системах, мобильных, промышленных, потребительских, коммуникационных и встраиваемых устройствах, которые потенциально могут стать объектами атак с использованием Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi и других внешних источников данных (например, могут быть атакованы доступные по сети сервисы и приложения, принимающие входные данные без ограничения размера).
В качестве примера приводится создание рабочего эксплоита для атаки на встроенный в автомобильные информационные системы http-сервер, доступный через автомобильную Wi-Fi сеть. Посторонний атакующий может эксплуатировать уязвимость в memcpy в данном сервере через передачу GET-запроса очень большого размера и получить root-доступ к системе.
https://www.opennet.ru/opennews/pics_base/0_1590093329.png (https://1.bp.blogspot.com/-jn5Ehvf41zM/XsaUrrbL_OI/AAAAAAAABtE/naydd40WyaApbJtZWKMokafBH7--HTNNQCLcBGAsYHQ/s1600/image20.png)
На 32-разрядных системах x86 проблема не проявляется, так как реализация memcpy для данной архитектуры корректно интерпретирует переменную с размером как беззнаковое целое значение с типом size_t (в написанной на ассемблере реализации (https://code.woboq.org/userspace/glibc/sysdeps/arm/memcpy.S.html) для ARMv7 вместо size_t оно обрабатывается как signed integer). Исправление пока доступно в виде патча (https://patchwork.sourceware.org/project/glibc/patch/ac494a6febda4430857df1fc31f64e19@huawei.com/), который войдёт в состав августовском обновлении Glibc 2.32. Исправление сводится к замене использования ассемблерных инструкций, оперирующих знаковыми операндами (bge и blt), на беззнаковые аналоги (blo и bhs).
Проблема пока не устранена в Debian 9 и 10 (https://security-tracker.debian.org/tracker/CVE-2020-6096) (в Debian 8 не проявляется), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1820332), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-6096.html), OpenEmbedded, Tizen (используется glibc). RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-6096) и SUSE (https://bugzilla.suse.com/show_bug.cgi?id=CVE-2020-6096) проблема не затрагивает, так как они не поддерживают 32-разрядные системы ARMv7. Android не подвержен уязвимости, так как использует собственную реализацию libc (Bionic). В OpenWRT (https://openwrt.org/advisory/start) по умолчанию в большинстве сборок используется Musl, но в репозитории имеется и glibc.
21.05.2020
https://www.opennet.ru/opennews/art.shtml?num=53003