Критическая уязвимость в glibc: переполнение буфера при вызове getaddrinfo() (CVE-2015-7547)

Пакет glibc предоставляет стандартные библиотеки, которые используются множеством системных программ. В целях экономии памяти и дискового пространства, а также облегчения процесса обновления системы, общий код, предназначенный для совместного использования программами, хранится в одном месте. Пакет glibc содержит стандартную библиотеку языка C, с которой работают практически все программы GNU/Linux. Входящая в его состав библиотека libresolv включает функции, отвечающие за преобразование имен узлов в IP-адреса. Эта библиотека, в свою очередь, используется модулем NSS (Name Service Switch)— nss_dns — также входящим в состав glibс.

Описание

Переполнение буфера стека является следствием уязвимости в коде libresolv, который вызывает одновременную отправку двух DNS-запросов A/AAAA, что дает возможность удаленному злоумышленнику целенаправленно сформировать ответ DNS, который должен спровоцировать ошибку libresolv и привести к удаленному выполнению кода с правами пользователя, запустившего библиотеку. Переполнение буфера происходит в функциях send_dg (для запросов UDP) и send_vc (для запросов TCP). Условия для эксплуатации уязвимости создаются при обращении к библиотеке libresolv из модуля nss_dns. Ей был присвоен код CVE-2015-7547.

Уязвимыми оказались все приложения, вызывающие функцию getaddrinfo с AF_UNSPEC. В Red Hat Enterprise Linux 6.4 в группу риска дополнительно попали приложения, работающие с адресами AF_INET6. Приложения, использующие более ранние функции gethostbyname и res_search, не могут быть скомпрометированы.

Эта проблема не затрагивает версии glibc в Red Hat Enterprise Linux 5 и более ранних релизах, но актуальна для Red Hat Enterprise Linux 6 и 7.

Степень воздействия

Red Hat оценивает эту уязвимость как КРИТИЧЕСКУЮ.

Меры предосторожности

В стандартной конфигурации libresolv вектор атаки на UDP пресекается благодаря использованию доверенного, совместимого преобразователя DNS в доверенной сети. Совместимый преобразователь DNS не будет создавать ответы большого размера (что как раз и является главной причиной переполнения буфера), так как по умолчанию преобразователь glibc не включает расширения EDNS0 и не запрашивает масштабирование ответов.

Вероятность направленной атаки на TCP минимизируется благодаря использованию доверенного рекурсивного преобразователя DNS, жестко ограничивающего размер ответов DNS 1023 байтами, в доверенной сети. Однако такой подход не находит широкого применения, так как он нарушает работу протокола DNS (параметр размера буфера, предлагаемый большинством преобразователей, применим только к UDP, а не к TCP). Отказ от обработки ответов AAAA без ограничения размера получаемых записей A не снизит вероятность несанкционированного доступа.

Отключение IPv6 в уязвимых системах не гарантирует их безопасность, так как двойные запросы A/AAAA будут по-прежнему выполняться даже при отсутствии поддержки IPv6.

Уязвимые продукты

Все версии пакета glibc в Red Hat Enterprise Linux 6 и 7 оказались уязвимы. Ниже приведена таблица с соответствующими рекомендациями безопасности.

Решение

После установки обновлений необходимо перезапустить уязвимые службы или полностью перезагрузить систему.

В силу того, что эта уязвимость затрагивает большую часть приложений в системе, наиболее эффективное решение заключается в устранении первопричины — то есть обновления самих пакетов glibc.

Если по объективным причинам после применения обновлений вы не можете перезагрузить систему, то для идентификации активных процессов, до сих пор использующих сохраненную в памяти уязвимую версию glibc, можно выполнить следующую команду:

lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t

В полученном списке найдите службы, взаимодействующие с открытой сетью, — их надо будет перезапустить. Следует помнить, что этот метод походит лишь как временный вариант и не поддерживается компанией Red Hat, поэтому в случае невозможности получения желаемого результата наши специалисты в первую очередь предложат перезагрузить систему и только после этого приступят к диагностике.

FAQ

1. Может ли SELinux блокировать эту уязвимость?
Правила SELinux в некоторой степени могут снизить уровень ущерба, ограничив уровень доступа к системе, но поскольку многие приложения и системные компоненты используют DNS, SELinux не может гарантировать абсолютную безопасность.

2. Может ли доверенный преобразователь DNS обеспечить достаточную защиту?
Доверенный преобразователь DNS в стандартной конфигурации не исключает риск несанкционированного доступа, так как эксплойт может включать синтаксически верно построенные ответы DNS.

3. А что насчет статического подключения glibc?
Red Hat не поддерживает статическое использование glibc, однако если клиент создал программную сборку со статическим подключением glibc-static, такое приложение все так же будет обращаться к системным копиям nss_dns и libresolv. Обновление пакетов glibc должно решить эту проблему.

Благодарности

Эта уязвимость была обнаружена командами безопасности Google и Red Hat.