В состав Glibc включено исправление уязвимости в memcpy, подготовленное разработчиками ОС Аврора
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Разработчики мобильной операционной системы "Аврора" (локализованный вариант ОС Sailfish, развиваемый компанией "Открытая мобильная платформа") поделились показательной историей об устранении критической уязвимости (CVE-2020-6096) в Glibc, проявляющейся только на платформе ARMv7. Сведения об уязвимости были раскрыты ещё в мае, но до последних дней исправления не были доступны, несмотря на то, что уязвимости присвоен высокий уровень опасности и доступен рабочий прототип эксплоита, позволяющий организовать выполнение кода при обработке в функциях memcpy() и memmove() определённым образом оформленных данных. Исправления пакетов для Debian и Ubuntu не выпущены до сих пор и уязвимость остаётся неисправленной почти два месяцев с момента публичного раскрытия и пять месяцев с момента уведомления разработчиков Glibc.
Уязвимость проявлялась в реализации memcpy() и memmove() на языке ассемблер для ARMv7 и была вызвана некорректной обработкой отрицательных значений параметра, определяющего размер копируемой области. Проблемы с разработкой патчей начались с того, что компании SUSE и Red Hat объявили, что их платформы проблеме не подвержены, так как они не формируют сборки для 32-разрядных систем ARMv7, и не стали участвовать в создании исправления. Разработчики многих встраиваемых дистрибутивов, видимо, положились на команду Glibc, и также не проявили активного участия в подготовке исправления.
Вариант патча для блокирования проблемы почти сразу предложила компания Huawei, которая попыталась заменить ассемблерные инструкции, оперирующие знаковыми операндами (bge и blt), на беззнаковые аналоги (blo и bhs). Мэйнтенеры Glibc разработали набор тестов для проверки разных условий возникновения ошибки, после чего выяснилось, что патч от Huawei не подходит и не обрабатывает все возможные комбинации входных данных.
Так как ОС Аврора имеет 32-битную сборку для ARM её разработчики решили закрыть уязвимость своими силами и предложить решение сообществу. Сложность заключалась в том, что нужно было написать эффективную ассемблерную реализацию функции и учесть при этом различные варианты входных аргументов. Реализация была переписана с использованием беззнаковых инструкций. Патч получился небольшой, но основная проблема состояла в сохранении скорости выполнения и исключении снижения производительности функций memcpy и memmove, сохраняя при этом совместимость со всеми комбинациями входных значений.
В начале июня было подготовлено два варианта исправления, проходящие тестовый фреймворк мейтенеров Glibc и внутренний тестовый набор Авроры. 3 июня был выбран один из вариантов и отправлен в список рассылки Glibc. Через неделю
был предложен ещё один аналогичный по подходу патч, который исправлял проблему в multiarch-реализации, которую ранее пытались исправить в Huawei. Месяц заняло тестирование и юридическое оформление в виду важности патча.
8 июля исправления были приняты в основную ветку готовящегося релиза glibc 2.32. Реализация включает два патча - первый для multiarch-реализации memcpy для ARMv7, а второй для общей ассемблерной реализации memcpy() и memmove() для ARM.
Проблема затрагивает миллионы ARMv7-устройств с Linux и без соответствующего обновления владельцы рискуют, подключая их к сети (атакованы могут быть доступные по сети сервисы и приложения, принимающие входные данные без ограничения размера). Например, в эксплоите, подготовленном выявившими уязвимость исследователями, показано как совершить атаку на встроенный в автомобильную информационную систему http-сервер через передачу GET-запроса очень большого размера и получить root-доступ к системе.
===========
Источник:
OpenNet.RU
===========
Похожие новости:
- [Программирование, Разработка под Linux] Как Linux'овский sort сортирует строки
- Checkpoint предложил технику защиты Safe-Linking, усложняющую эксплуатацию уязвимостей
- Уязвимость в реализации функции memcpy для ARMv7 из состава Glibc
- Обновление почтового сервера Postfix 3.5.1
- Выпуск системной библиотеки Glibc 2.31
- Выпуск системной библиотеки Glibc 2.30
- Выпуск системной библиотеки Glibc 2.29
- Выпуск системной библиотеки Glibc 2.28
- Конфликт между Ричардом Столлманом и командой разработчиков Glibc
- Выпуск системной библиотеки Glibc 2.27
Теги для поиска: #_glibc
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:22
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Разработчики мобильной операционной системы "Аврора" (локализованный вариант ОС Sailfish, развиваемый компанией "Открытая мобильная платформа") поделились показательной историей об устранении критической уязвимости (CVE-2020-6096) в Glibc, проявляющейся только на платформе ARMv7. Сведения об уязвимости были раскрыты ещё в мае, но до последних дней исправления не были доступны, несмотря на то, что уязвимости присвоен высокий уровень опасности и доступен рабочий прототип эксплоита, позволяющий организовать выполнение кода при обработке в функциях memcpy() и memmove() определённым образом оформленных данных. Исправления пакетов для Debian и Ubuntu не выпущены до сих пор и уязвимость остаётся неисправленной почти два месяцев с момента публичного раскрытия и пять месяцев с момента уведомления разработчиков Glibc. Уязвимость проявлялась в реализации memcpy() и memmove() на языке ассемблер для ARMv7 и была вызвана некорректной обработкой отрицательных значений параметра, определяющего размер копируемой области. Проблемы с разработкой патчей начались с того, что компании SUSE и Red Hat объявили, что их платформы проблеме не подвержены, так как они не формируют сборки для 32-разрядных систем ARMv7, и не стали участвовать в создании исправления. Разработчики многих встраиваемых дистрибутивов, видимо, положились на команду Glibc, и также не проявили активного участия в подготовке исправления. Вариант патча для блокирования проблемы почти сразу предложила компания Huawei, которая попыталась заменить ассемблерные инструкции, оперирующие знаковыми операндами (bge и blt), на беззнаковые аналоги (blo и bhs). Мэйнтенеры Glibc разработали набор тестов для проверки разных условий возникновения ошибки, после чего выяснилось, что патч от Huawei не подходит и не обрабатывает все возможные комбинации входных данных. Так как ОС Аврора имеет 32-битную сборку для ARM её разработчики решили закрыть уязвимость своими силами и предложить решение сообществу. Сложность заключалась в том, что нужно было написать эффективную ассемблерную реализацию функции и учесть при этом различные варианты входных аргументов. Реализация была переписана с использованием беззнаковых инструкций. Патч получился небольшой, но основная проблема состояла в сохранении скорости выполнения и исключении снижения производительности функций memcpy и memmove, сохраняя при этом совместимость со всеми комбинациями входных значений. В начале июня было подготовлено два варианта исправления, проходящие тестовый фреймворк мейтенеров Glibc и внутренний тестовый набор Авроры. 3 июня был выбран один из вариантов и отправлен в список рассылки Glibc. Через неделю был предложен ещё один аналогичный по подходу патч, который исправлял проблему в multiarch-реализации, которую ранее пытались исправить в Huawei. Месяц заняло тестирование и юридическое оформление в виду важности патча. 8 июля исправления были приняты в основную ветку готовящегося релиза glibc 2.32. Реализация включает два патча - первый для multiarch-реализации memcpy для ARMv7, а второй для общей ассемблерной реализации memcpy() и memmove() для ARM. Проблема затрагивает миллионы ARMv7-устройств с Linux и без соответствующего обновления владельцы рискуют, подключая их к сети (атакованы могут быть доступные по сети сервисы и приложения, принимающие входные данные без ограничения размера). Например, в эксплоите, подготовленном выявившими уязвимость исследователями, показано как совершить атаку на встроенный в автомобильную информационную систему http-сервер через передачу GET-запроса очень большого размера и получить root-доступ к системе. =========== Источник: OpenNet.RU ===========
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:22
Часовой пояс: UTC + 5