Кэйс Кук (Kees Cook), бывший главный сисадмин kernel.org и лидер Ubuntu Security Team, ныне работающий в компании Google над обеспечением защиты ChromeOS, объявил (http://openwall.com/lists/kernel-hardening/2015/11/05/1) о создании проекта Kernel Self Protection Project (http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pro...), в рамках которого планируется сформировать сообщество для развития и продвижения в основное ядро Linux технологий активной защиты, большинство из которых уже подготовлены в рамках проектов PaX (https://pax.grsecurity.net/) и Grsecurity (https://grsecurity.net/). Финансирование и ресурсы для проведения работ будут предоставлены организацией Linux Foundation и участниками программы Core Infrastructure Initiative (https://www.opennet.ru/opennews/art.shtml?num=39635).
Создание нового проекта поможет обойти проблемы с неэффективным процессом (http://www.washingtonpost.com/sf/business/2015/11/05/net-of-.../) координации устранения уязвимостей в ядре, которые исправляются наряду с обычными ошибками без уделения им дополнительного внимания и не приводя к формированию внеплановых релизов. В частности, в сообществе разработчиков ядра системный механизм выявления и устранения проблем на ранних стадиях, до момента когда злоумышленники получат доступ к информации о потенциальной уязвимости. Кроме того, отсутствует ответственный за безопасность ядра.
Позиция Линуса Торвальдса сводится к тому, что уязвимости исправляются в рамках обычного цикла принятия исправлений, без дополнительного приоритета и привлечения внимания. Задача по оперативной доставке исправлений уязвимостей и выделению потенциальных проблем с безопасности из общего потока правок ложится на команды, занимающиеся поддержкой пакетов с ядром для дистрибутивов Linux. Таким образом, информация об исправлениях, которые могут быть связаны с уязвимостями становится доступна одновременно и для злоумышленников и для команд по обеспечению безопасности дистрибутивов. Более того, жизненный цикл уязвимостей в ядре достаточно велик и проблемы могут всплывать лишь спустя годы после своего появления. Используя методы статического анализа и fuzzing-тестирования злоумышленники имеют возможность выявлять проблемы до их обнаружения и исправления разработчиками ядра.
В таких условиях привычная работа по обеспечению безопасности через оперативное исправление уязвимостей становится неэффективной. Уязвимость в ядре может свести на нет все механизмы контроля доступа и средства защиты, работающие на уровне пользователя. Включение в ядро активных механизмов защиты позволит затруднить проведение новых атак и блокировать эксплуатацию ещё неисправленных уязвимостей. Вместо противодействия конкретным уязвимостям гораздо выгоднее блокировать целые классы проблем, такие как переполнения стека, целочисленные переполнения, переполнения кучи, проблемы с форматированием строк, утечка указателей ядра и неинициализированные переменные.
Среди возможностей активной защиты, которые рассматриваются для добавления в первую очередь, отмечаются использование gcc-плагинов и патчей PAX_SIZE_OVERFLOW, PAX_REFCOUNT, PAX_USERCOPY, GRKERNSEC_KSTACKOVERFLOW, PAX_MEMORY_STACKLEA, PAX_CONSTIFY_PLUGIN, GRKERNSEC_HIDESYM, PAX_KERNEXEC и PAX_MEMORY_UDEREF. Из желательных для блокирования методов эксплуатации выделяются определение размещения ядра в памяти, перезапись текста, перезапись указателей на функции, инициирования из ядра выполнения кода в пространстве пользователя и доступа к данным в пространстве пользователя.
URL: http://openwall.com/lists/kernel-hardening/2015/11/05/1
Новость: http://www.opennet.ru/opennews/art.shtml?num=43274
