Два года изменение в Linux оставляло ключи шифрования диска в оперативке при засыпании

Регрессия и оговорки, которые к ней прилагаются

Пост Инго Блехшмидта (mathstodon.xyz/@iblech) сообщает: с Linux 6.9 путь cryptsetup luksSuspend, который должен стирать мастер-ключ LUKS из оперативки перед suspend-to-RAM, тихо перестал это делать, и ключ шифрования диска оставался в памяти при засыпании больше двух лет. Как один читатель процитировал источник: ключ «оставался в памяти при засыпании, доступным любому, кто завладеет всё ещё запитанным ноутбуком». По сообщениям, для отлова регрессии в будущем добавили тест на NixOS. (Источник в Mastodon не отрендерился для этого выпуска, так что относитесь к деталям как к сообщённым, но не проверенным.)

Две поправки из треда меняют оценку серьёзности. Во-первых, охват:

«этот cryptsetup luksSuspend… официально толком не поддерживается, это расширение, сделанное в Debian, так что регрессия, если что, задела только Debian?… по заголовку же кажется, будто проблема повсеместная, а не касается одного дистрибутива.» — читатель, проследивший механизм до расширения, специфичного для Debian

Во-вторых, модель угроз:

«Очевидно же, что при пробуждении ноутбук заблокирован; как тогда ключ может быть «доступен любому»? Я не говорю, что считать RAM из заблокированного ноутбука невозможно, но уж точно не «любому».» — комментатор, ставящий под сомнение практическую эксплуатируемость

Починка, доступная большинству

Повторяющийся практичный совет: вообще не полагаться на стирание ключа и просто обесточить память:

«На своём ноутбуке с Fedora я просто настроил Linux уходить в гибернацию на диск после 15 минут сна. Обесточивание памяти гарантирует, что баги вроде этого, специфичного для Debian, не будут иметь значения… Так что гибернация по сути единственный нормальный способ защититься от cold boot.» — пользователь Fedora, включивший автогибернацию как меру защиты

Другие спустились ниже по стеку, включив полное шифрование памяти Intel, чтобы открытый текст вообще не покидал корпус процессора. Урок не в том, что «Linux 6.9 сломал шифрование для всех». Он уже и тревожнее: страховочный шаг, работающий незаметно на редко тестируемом участке кода, может перестать работать, и никто не заметит два года. Защиту, которая держится на невидимом стирании, стоит считать находящейся в одной регрессии от выключенного состояния.