Обнаружена критическая уязвимость в 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 следует не забыть перезапустить сетевые приложения.

Smart App Control в Windows 11 теперь можно выключать без переустановки ОС

Microsoft наконец-то сделала шаг навстречу пользователям Windows 11 и ослабила один из самых жёстких защитных механизмов системы. Начиная со сборки Windows 11 Insider Preview Build 26220.7070, Smart App Control теперь можно включать и выключать в любой момент — без обязательной «чистой» переустановки системы. Обновление уже начали получать участники Dev- и Beta-каналов.

Переключатель появился по привычному пути: «Безопасность Windows» → «Управление приложениями и браузером» → Smart App Control.

При включении функция по-прежнему блокирует недоверенные и потенциально опасные приложения, но теперь решение не становится фатальным.

Раньше Smart App Control работал по принципу «один шанс на всю жизнь системы». Если пользователь отключал его хотя бы один раз, Windows навсегда блокировала возможность включить защиту обратно. Единственным выходом оставалась полная переустановка или сброс Windows 11. В итоге пользователям приходилось выбирать: либо терпеть сломанные легитимные приложения, либо отказаться от Smart App Control навсегда.

 

Smart App Control задумывался как «привратник» Windows 11. В отличие от классического антивируса, он не проверяет программы постфактум, а пытается остановить их ещё до запуска. Для этого используются сервисы app intelligence Microsoft и механизмы проверки целостности кода. Всё неизвестное, неподписанное или подозрительное просто не запускается. В теории — отличная защита от зловредов, PUA и атак 0-day.

На практике же функция регулярно мешала нормальной работе. И, похоже, в Microsoft это всё-таки признали. Новый апдейт не меняет логику блокировок, но избавляет пользователей от пожизненного «наказания» за одно неверное решение.

До настоящего момента у Smart App Control был крайне жёсткий жизненный цикл. Он работал только после чистой установки Windows 11 или полного сброса системы. При обновлении с более старых версий Windows функция по умолчанию оставалась отключённой.

После установки Smart App Control переходил в режим оценки. Примерно неделю он молча наблюдал за тем, как пользователь работает с устройством: какие приложения запускает, какие бинарники использует, насколько его поведение укладывается в модель «безопасного пользователя». На этом этапе ничего не блокировалось.

Если Windows решала, что пользователь подходит под строгий контроль, Smart App Control автоматически включался в режим принудительного исполнения. С этого момента начинались реальные ограничения: неизвестные или неподписанные приложения просто не запускались. Кнопки «Запустить всё равно», исключений или белых списков не существовало.

Самое неприятное — если пользователь вручную отключал Smart App Control хотя бы один раз, система навсегда считала это решение окончательным. Windows даже не предупреждала, что откат невозможен. Особенно сильно от этого страдали разработчики, геймеры, стримеры и продвинутые пользователи, которые часто используют нестандартный или часто обновляемый софт. На Reddit регулярно появлялись жалобы на блокировку вполне легитимных программ.

 

В сборке 26220.7070 Microsoft убрала это ограничение. Теперь Smart App Control можно свободно включать и отключать без переустановки системы. Изменение распространяется постепенно и пока доступно только в Dev- и Beta-каналах.

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