В Linux 6.9 регрессия cryptsetup, ключи шифрования остаются в памяти при suspend

С выходом Linux 6.9 в cryptsetup появилась критическая регрессия. Функция luksSuspend, которая должна была удалять ключи шифрования диска из памяти перед приостановкой системы (suspend), перестала это делать. При включении компьютера пользователь видит запрос на ввод пароля, что создаёт впечатление нормальной работы функции. Однако копия ключа шифрования на самом деле остаётся в памяти ядра.

Проблема в основном затронула пользователей Debian и производных дистрибутивов, которые используют пакет cryptsetup-suspend. Техническая причина: ядро изменило поведение потоковых колец ключей, и cryptsetup полагался на гарантию, что «кольцо ключей потока уничтожается при завершении потока». Это нарушение гарантии привело к тому, что ключи остаются в памяти.

Уязвимость особенно коварна, потому что практически не обнаруживается, с точки зрения пользователя всё работает нормально. Теоретически ключ может быть извлечён при физическом доступе к машине, хотя такие атаки требуют специального оборудования и навыков. В обсуждении на Hacker News высказывались разные мнения о практической опасности этой уязвимости в зависимости от модели угроз.

Возможные решения включают добавление регрессионных тестов для предотвращения повторения проблемы, переход на гибернацию (которая полностью отключает ОЗУ вместо его сохранения), или использование встроенного шифрования памяти на современных процессорах AMD и Intel, которое работает с минимальным оверхедом.

Ключевые факты

  • Регрессия с Linux 6.9: cryptsetup luksSuspend перестаёт стирать ключи из памяти, хотя запрос пароля при включении создаёт иллюзию работоспособности
  • Ключи шифрования остаются в памяти ядра и могут быть извлечены при физическом доступе к заблокированной машине
  • Проблема затронула Debian и дистрибутивы, использующие cryptsetup-suspend, из-за нарушения гарантии ядра о потоковых кольцах ключей
  • Уязвимость скрытая, пользователь не видит признаков неполадки, что увеличивает риск нераспознавания проблемы
  • Решения: регрессионные тесты в дистрибутивах, переход на гибернацию или использование аппаратного шифрования памяти на новых процессорах

Почему это важно

Шифрование диска, стандартная мера защиты данных на ноутбуках и десктопах. Функция suspend (режим сна) предполагает сохранение состояния ОЗУ, но при этом ключ шифрования должен быть стёрт для безопасности. Регрессия нарушает эту гарантию: ключ остаётся в памяти, что позволяет потенциальному злоумышленнику с физическим доступом к машине прочитать зашифрованный диск без ввода пароля. Это особенно опасно, если ноутбук украден или конфискован в выключенном состоянии с включённым режимом suspend.

Кому это важно

Проблема затронула в первую очередь пользователей Debian и его производных (Ubuntu, Linux Mint и т.д.), которые используют пакет cryptsetup-suspend для автоматической защиты ключей при sleep. Также это касается людей, которые рассчитывают на полную защиту данных при приостановке системы, особенно работающих с чувствительной информацией (журналисты, исследователи, активисты, люди в странах с высокими рисками конфискации). Даже если угроза физического доступа к машине кажется маловероятной, наличие скрытой уязвимости без видимых признаков нарушает модель доверия.

Как это применить

Пользователям Debian и производных дистрибутивов рекомендуется немедленно обновиться до версии Linux > 6.9 с исправленной регрессией. Альтернативный подход: использовать гибернацию (hibernate) вместо suspend, при гибернации содержимое ОЗУ записывается на диск и ОЗУ полностью отключается, что полностью исключает риск утечки ключей. Для максимальной защиты на новых системах AMD Ryzen с шифрованием памяти (Memory Encryption) или Intel с аналогичной технологией можно дополнительно включить аппаратное шифрование ОЗУ, хотя это имеет минимальный оверхед.

Можно ли доверять

Информация о регрессии исходит из обсуждения на Hacker News (крупнейший технологический форум с экспертной аудиторией) со ссылкой на пост специалиста по Mastodon. Проблема подтверждена комментариями от людей, работающих с cryptsetup и дистрибутивами. Регрессия в Linux 6.9, задокументированный факт, и сама уязвимость реальна. Однако в обсуждении были разные оценки практической угрозы в зависимости от предположений о способности злоумышленника извлечь ОЗУ, что требует специального оборудования.

Риски и подводные камни

Главный риск, скрытость уязвимости. Пользователь видит, что система просит пароль при включении, и считает функцию работающей. На самом деле ключ остаётся в памяти, но это невозможно обнаружить стандартными средствами. Второй риск: не все дистрибутивы используют cryptsetup-suspend по умолчанию, поэтому многие пользователи Linux 6.9 могут вообще не быть затронуты. Третий: переход на гибернацию вместо suspend замедляет время включения/выключения и требует свободного места на диске. Четвёртый: аппаратное шифрование памяти доступно только на новых процессорах и может привести к несовместимости со старым оборудованием.