grimnir
17.02.2016, 14:44
https://habrahabr.ru/company/pt/blog/277383/
Исследователи Google обнаружили (https://googleonlinesecurity.blogspot.ru/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html) критическую уязвимость в библиотеке glibc (GNU C Library (https://ru.wikipedia.org/wiki/Glibc)). В функции getaddrinfo(), которая отвечает за разбор доменных имен, происходит переполнение буфера — ошибка позволяет злоумышленникам осуществлять удаленное выполнение кода.
Эксплуатация уязвимости, получившей обозначение CVE-2015-7547 (https://www.redhat.com/security/data/cve/CVE-2015-7547.html), возможна в случаях, когда уязвимые устройства или приложения отправляют запросы контролируем хакерами доменам и серверам, а также в случае проведения атаки типа man-in-the-middle.
Все очень серьезно
В своем блоге исследователи Google пишут, что обнаружили уязвимость, когда в используемом ими SSH-клиенте при попытке соединения с определенным адресом раз за разом начала возникать ошибка сегментации. В ходе разбирательств выяснилось, что всему виной переполнение буфера в glibc, и что эта ошибка может приводить к удаленному выполнению кода.
Библиотека glibc используется в большом количестве популярных Linux-приложений — по утверждениям исследователей, уже подтверждена информация об уязвимости утилит wget, SSH, sudo и curl. Общее число уязвимых приложений столь велико, что составить полный список не представляется возможным — в разговоре с изданием Ars Technica исследователь безопасности Кен Уайт (http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/) заявил, что уязвимость содержится во всех дистрибутивах Linux, а также языках программирования Python, PHP, Ruby on Rails. Есть сообщения (https://www.reddit.com/r/Bitcoin/comments/46354z/most_bitcoin_clients_affected_by_glibc_dns/) о том, что ошибка содержится и в большей части приложений для работы с криптовалютой биткоин.
К удивлению исследователей, оказалось, что мейнтейнеры, ответственные за glibc, знали об ошибке еще в июле (https://sourceware.org/bugzilla/show_bug.cgi?id=18665) прошлого года. Кроме того, выяснилось, что параллельно с экспертами Google и независимо от них уязвимость обнаружили и специалисты Red Hat — продукты этой компании также уязвимы (список (https://access.redhat.com/errata/RHSA-2016:0175)). В итоге две команды объединили усилия для создания патча.
На Github также доступна proof-of-concept-реализация эксплоита (https://github.com/fjserna/CVE-2015-7547).
Как защититься
Специалисты, занимающиеся поддержкой glibc, уже выпустили патч (https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html), исправляющий ошибку. В некоторых случаях достаточно просто установить его, однако, если софт был скомпилирован с использованием уязвимой версии glibc, то его потребуется перекомпилировать с новой версией.
Если установить патч по какой-то причине невозможно, исследователи описывают способы снижения вероятности эксплуатации уязвимости. Прежде всего, для эксплуатации необходимы большие пакеты UDP или TCP-ответов (2048+ байт) — приходящие один за одним такие пакеты перезаписывают стек. Противодействовать этому можно, ограничив размер пакетов с ответами, которые принимает локальный DNS-резолвер. Сделать это можно с помощью DNSMasq или аналогичных программ. Кроме того, следует убедиться, что DNS-запросы отправляются только DNS-серверам, которые ограничивают размер UDP-ответов.
Мейнтейнеры glibc дали и свои рекомендации по противодействию атакам с использованием уязвимости. Они включают использование межсетевого экрана, который отклоняет UDP DNS-пакеты размером больше 512 байт, отказ от использования AF_UNSPEC, `options edns0` в /etc/resolv.conf, а также`RES_USE_EDNS0` или `RES_USE_DNSSEC`.
Существуют и пакеты, которые не содержат эту ошибку — например, в мобильной ОС Google Android вместо glibc иcпользуется библиотека Bionic (https://en.wikipedia.org/wiki/Bionic_%28software%29). Кроме того, многие используемые частными пользователями устройства —например, домашние роутеры — также работают с установленными альтернативными glibc библиотеками, об уязвимости которых информации на данный момент нет.
Исследователи Google обнаружили (https://googleonlinesecurity.blogspot.ru/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html) критическую уязвимость в библиотеке glibc (GNU C Library (https://ru.wikipedia.org/wiki/Glibc)). В функции getaddrinfo(), которая отвечает за разбор доменных имен, происходит переполнение буфера — ошибка позволяет злоумышленникам осуществлять удаленное выполнение кода.
Эксплуатация уязвимости, получившей обозначение CVE-2015-7547 (https://www.redhat.com/security/data/cve/CVE-2015-7547.html), возможна в случаях, когда уязвимые устройства или приложения отправляют запросы контролируем хакерами доменам и серверам, а также в случае проведения атаки типа man-in-the-middle.
Все очень серьезно
В своем блоге исследователи Google пишут, что обнаружили уязвимость, когда в используемом ими SSH-клиенте при попытке соединения с определенным адресом раз за разом начала возникать ошибка сегментации. В ходе разбирательств выяснилось, что всему виной переполнение буфера в glibc, и что эта ошибка может приводить к удаленному выполнению кода.
Библиотека glibc используется в большом количестве популярных Linux-приложений — по утверждениям исследователей, уже подтверждена информация об уязвимости утилит wget, SSH, sudo и curl. Общее число уязвимых приложений столь велико, что составить полный список не представляется возможным — в разговоре с изданием Ars Technica исследователь безопасности Кен Уайт (http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/) заявил, что уязвимость содержится во всех дистрибутивах Linux, а также языках программирования Python, PHP, Ruby on Rails. Есть сообщения (https://www.reddit.com/r/Bitcoin/comments/46354z/most_bitcoin_clients_affected_by_glibc_dns/) о том, что ошибка содержится и в большей части приложений для работы с криптовалютой биткоин.
К удивлению исследователей, оказалось, что мейнтейнеры, ответственные за glibc, знали об ошибке еще в июле (https://sourceware.org/bugzilla/show_bug.cgi?id=18665) прошлого года. Кроме того, выяснилось, что параллельно с экспертами Google и независимо от них уязвимость обнаружили и специалисты Red Hat — продукты этой компании также уязвимы (список (https://access.redhat.com/errata/RHSA-2016:0175)). В итоге две команды объединили усилия для создания патча.
На Github также доступна proof-of-concept-реализация эксплоита (https://github.com/fjserna/CVE-2015-7547).
Как защититься
Специалисты, занимающиеся поддержкой glibc, уже выпустили патч (https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html), исправляющий ошибку. В некоторых случаях достаточно просто установить его, однако, если софт был скомпилирован с использованием уязвимой версии glibc, то его потребуется перекомпилировать с новой версией.
Если установить патч по какой-то причине невозможно, исследователи описывают способы снижения вероятности эксплуатации уязвимости. Прежде всего, для эксплуатации необходимы большие пакеты UDP или TCP-ответов (2048+ байт) — приходящие один за одним такие пакеты перезаписывают стек. Противодействовать этому можно, ограничив размер пакетов с ответами, которые принимает локальный DNS-резолвер. Сделать это можно с помощью DNSMasq или аналогичных программ. Кроме того, следует убедиться, что DNS-запросы отправляются только DNS-серверам, которые ограничивают размер UDP-ответов.
Мейнтейнеры glibc дали и свои рекомендации по противодействию атакам с использованием уязвимости. Они включают использование межсетевого экрана, который отклоняет UDP DNS-пакеты размером больше 512 байт, отказ от использования AF_UNSPEC, `options edns0` в /etc/resolv.conf, а также`RES_USE_EDNS0` или `RES_USE_DNSSEC`.
Существуют и пакеты, которые не содержат эту ошибку — например, в мобильной ОС Google Android вместо glibc иcпользуется библиотека Bionic (https://en.wikipedia.org/wiki/Bionic_%28software%29). Кроме того, многие используемые частными пользователями устройства —например, домашние роутеры — также работают с установленными альтернативными glibc библиотеками, об уязвимости которых информации на данный момент нет.