Правильная настройка безопасности гласит... когда ноут уходит в спящий режим, система обязана затереть ключи шифрования диска в оперативке. Это базовая защита от атак методом холодной перезагрузки.
Но, внезапно, независимый исследователь Инго Блехшмидт раскопал ужасное. Оказалось, что начиная с релиза ядра 6.9 (а это, на минуточку, май 2024 года!) механизм затирки ключей тупо перестал работать 😶. Можно было прописывать что угодно в конфигах, но при переходе в спящий режим ядро оставляло ключи от LUKS висеть в оперативке в открытом виде.
Виновником оказался коммит a28d893eb327, выполнявший перевод подсистемы
block/md на новую структуру файлов ядра, что неожиданно сломало логику работы механизма luksSuspend.Как бы выглядела схема атаки в реале:
Объект закрывает крышку ноута и идет пить кофе. Злоумышленник крадет девайс, переворачивает его, замораживает плашки RAM (баллончиком со сжатым воздухом или жидким азотом, чтобы замедлить деградацию заряда), вытаскивает память и дампит ее на спец.стенде. ПРОФИТ! Мастер-ключ от LUKS у хакера в руках, криптоконтейнер с ценными данными вскрыт без всякого брутфорса.
Два года вся эта дыра работала на современных дистрибутивах Linux 😗
Разрабы ядра признали баг, быстро зафиксили его костылём, но добавили в комментах, что @это не является комплексным решением проблемы".
В файле
drivers/md/dm.c был добавлен макрос scoped_with_kernel_creds():/* Открываем нижележащее устройство с привилегиями ядра,
а не вызывающего процесса. Иначе учетные данные процесса
привязываются к файлу и не дают очистить thread keyring,
из-за чего cryptsetup сливает ключ LUKS в память. */
scoped_with_kernel_creds()
bdev_file = bdev_file_open_by_dev(dev, mode, _dm_claim_ptr, NULL);
Этот вызов заставляет ядро открывать диск от имени самого ядра (а не от юзера). Из-за этого девайс больше не держит мертвым грузом пользовательские ключи исходного процесса
cryptsetup, и они успешно вычищаются сборщиком мусора сразу после закрытия программы.З.Ы. Только
shutdown -h now с полным обесточиванием железа.Типичный 🥸 Сисадмин