Обнаружена критическая уязвимость в Glibc

Обнаружена критическая уязвимость в Glibc

В системной библиотеке Glibc выявлена критическая уязвимость (CVE-2015-0235), которая может использоваться для организации выполнения кода в системе и проявляется при обработке специально оформленных данных в функциях gethostbyname() и gethostbyname2(), которые используются во многих программах для преобразования имени хоста в IP-адрес.

По степени опасности уязвимость, которая получила кодовое имя GHOST, сравнима с уязвимостями в Bash и OpenSSL. Для демонстрации уязвимости подготовлен рабочий прототип эксплоита, позволяющий организовать удалённое выполнение кода на почтовом сервере Exim, обойдя все доступные механизмы дополнительной защиты (ASLR, PIE, NX) на 32- и 64-разрядных системах, сообщает opennet.ru.

Проблема вызвана переполнением буфера в функции __nss_hostname_digits_dots(), используемой в gethostbyname() и gethostbyname2(). Несмотря на то, что вызовы gethostbyname() и gethostbyname2() устарели (следует использовать getaddrinfo()), они продолжают применяться для преобразования имени хоста во многих актуальных приложениях. Атака затруднена в серверных программах, которые используют gethostbyname() для обратной проверки данных, полученных через DNS, а также в привилегированных suid-утилитах, в которых вызов getaddrinfo() применяется только при сбое выполнения inet_aton(). Опасность представляют в основном приложения, передающие в getaddrinfo() данные, полученные извне, такие как почтовые серверы и манипулирующие именами хостов утилиты. Например, уязвимость подтверждена в Exim (при использовании настроек "helo_verify_hosts", "helo_try_verify_hosts" или ACL "verify = helo"), procmail и clockdiff.

Примечательно, что проблема присутствует в коде Glibc начиная с версии 2.2, выпущенной в ноябре 2000 года. При этом проблема была молча устранена в мае 2013 года без указания на то, что исправленная ошибка имеет отношение к серьёзным проблемам с безопасностью. Glibc 2.18 и более новые выпуски не подвержены уязвимости. Уязвимость не проявляется в дистрибутивах, построенных на основе свежих версий Glibc, например, в последних версиях Fedora и Ubuntu.

При этом, уязвимости подвержены длительно поддерживаемые промышленные дистрибутивы, которые требуют незамедлительного обновления. В частности, проблема проявляется в Debian 7 (wheezy), Red Hat Enterprise Linux 6 и 7, CentOS 6 и 7, Ubuntu 10.04 и 12.04, SUSE Linux Enterprise 10 и 11. В настоящее время обновление уже выпущено для Ubuntu 10.04/12.04, Debian 7 и RHEL 7,6,5. На стадии подготовки обновления для SUSE и CentOS. После обновления glibc следует не забыть перезапустить сетевые приложения.

Нейросети и ДНК: ИИ-лидеры просят закрыть лазейку для биооружия

В ИИ-индустрии произошло почти невероятное событие. Главы OpenAI, Anthropic, Google DeepMind и Microsoft AI выступили единым фронтом и попросили Конгресс США срочно ужесточить правила продажи синтетической ДНК и РНК.

3 июня Сэм Альтман, Дарио Амодеи, Демис Хассабис и Мустафа Сулейман подписали открытое письмо, в котором призвали обязать компании, занимающиеся синтезом генетического материала, проверять не только сами заказы, но и их заказчиков.

Причина проста: ИИ становится слишком хорошим помощником. Авторы письма опасаются, что современные языковые модели постепенно снижают порог входа в область биотехнологий.

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

Впрочем, паники в письме нет. Подписанты отдельно подчёркивают, что современные ИИ-модели пока не способны самостоятельно разработать полноценный патоген с нуля. Для этого всё ещё нужны профессиональные знания и практические навыки.

Но проблема, по их мнению, в другом: защитные барьеры постепенно размываются, а значит, лучше закрывать уязвимости заранее, чем ждать первого громкого инцидента.

Особенно тревожит экспертов рынок синтетической ДНК. Сегодня заказать нужную генетическую последовательность можно сравнительно быстро и недорого. А если ИИ поможет подобрать или замаскировать опасный заказ, существующие системы контроля могут не справиться.

В качестве примера авторы приводят исследование Microsoft, опубликованное в прошлом году. Тогда ИИ-системы для проектирования белков смогли сгенерировать потенциально опасные последовательности, которые прошли мимо фильтров поставщиков. Формально это были новые белки, но по структуре они напоминали уже известные опасные образцы.

Из этого подписанты делают вывод: проверять нужно не только клиентов биотехнологических компаний, но и сами ИИ-системы. Иными словами, фильтры безопасности придётся строить сразу на нескольких уровнях.

Любопытно, что главным событием здесь многие считают даже не содержание письма, а список подписантов. Когда Альтман и Амодеи оказываются под одним документом, значит, вопрос действительно считают серьёзным.

RSS: Новости на портале Anti-Malware.ru