Инфобез
16 лет в тени: уязвимость CVE-2026-53359 Januscape в KVM позволяет угнать физический сервер
В коде KVM для архитектуры x86 нашли древнейшую уязвимость, которая жила в ядре Linux незамеченной без малого 16 лет.
Проблеме присвоили индекс CVE-2026-53359, а сам исследователь Хёнву Ким назвал её Januscape.
Баг позволяет арендатору обычной виртуальной машины полностью взломать физический хост, на котором она крутится.
Корни проблемы уходят аж в 2010 год.
Ошибка прячется в механизме теневых страниц (shadow paging) для подсистемы управления памятью KVM.
Если гостевая ОС хитро манипулирует каталогами страниц, хост путает параметры и тип данных, из-за чего возникает классическая уязвимость Use-After-Free — обращение к уже освобожденной памяти. В контролируемой среде это позволяет устроить полноценный побег из виртуалки и получить права root прямо на самом сервере.
Для облачных провайдеров и хостингов это критическая история.
Злоумышленнику достаточно легально арендовать одну дешевую виртуалку и получить в ней root-права (что стандартно для любого облака).
С этого момента он может либо намертво уронить весь гипервизор в Kernel Panic, отключив соседей, либо перехватить контроль над всеми остальными клиентскими машинами на этом железе.
Чтобы провернуть такой трюк, на хосте должна быть включена вложенная виртуализация (nested virtualization).
Даже если вы используете современные аппаратные решения вроде Intel EPT или AMD NPT, активация nested virt всё равно заставляет KVM переключаться на тот самый старый уязвимый код теневого MMU.
Кроме того, опасность грозит и обычным серверам без запущенных виртуалок, если к файлу /dev/kvm есть доступ у непривилегированных локальных пользователей или взломанных веб-сервисов — они могут запустить свою микро-ВМ и через неё атаковать ядро.
Разработчики уже выкатили исправления.
Для полной защиты ядра требуются два связанных коммита: 81ccda30b4e8 и сопровождающий его 0cb2af2ea66a.
Патчи вошли в свежие стабильные ветки Linux (включая 6.12.95, 6.6.144, 6.1.177 и даже старые LTS-релизы вроде 5.15.211).
Пока мейнстримные дистрибутивы обновляют свои репозитории, лучшая временная мера — полностью отключить вложенную виртуализацию на хост-машинах.
Делается это через конфигурационные файлы в /etc/modprobe.d/, где для модулей kvm_intel или kvm_amd нужно жестко прописать параметр nested=0.
Также не лишним будет проверить права на /dev/kvm и убедиться, что туда не могут писать обычные пользователи или сомнительные Docker-контейнеры.
Как закрыть уязвимость KVM без перезагрузки сервера
Прилетело критическое обновление безопасности для KVM, а на проде крутятся боевые сервисы?
Гасить сервер ради одного патча ядра — так себе история. Защитить сервер от атаки Januscape можно прямо на лету, не дожидаясь планового техпроцесса и не выключая работающие виртуалки.
Вот рабочий план, как прикрыть брешь.
Шаг 1. Проверяем статус вложенной виртуализации
Вектор этой атаки завязан на nested-режим. Для начала нужно выяснить, активен ли он вообще на вашем железе. Вбиваем в терминал команду под свой процессор.
Если у вас Intel:
cat /sys/module/kvm_intel/parameters/nested
Если у вас AMD:
cat /sys/module/kvm_amd/parameters/nested
Смотрим на ответ системы:
-
Если прилетело
Yили1— сервер в зоне риска, функция работает. -
Если видите
Nили0— выдыхаем, этот путь для хакеров уже закрыт.
Шаг 2. Вырубаем nested-режим в памяти
Дергать модули ядра на живом хосте с запущенными машинами нельзя — всё рухнет. Но мы можем изменить параметры модулей прямо в памяти через sysfs.
Для процессоров Intel:
echo 0 | sudo tee /sys/module/kvm_intel/parameters/nested
Для процессоров AMD:
echo 0 | sudo tee /sys/module/kvm_amd/parameters/nested
После этого проверяем статус еще раз, как в первом шаге. Там должен железно гореть ноль. Теперь новые или перезапущенные виртуалки до опасного старого кода теневых страниц уже не дотянутся.
Шаг 3. Перекрываем доступ к /dev/kvm
Взломщик может использовать обычного локального пользователя или хакнутый веб-сервис на хосте, чтобы поднять свою микро-ВМ и через неё атаковать ядро. Чтобы этого не произошло, временно режем права на устройство KVM:
sudo chmod 600 /dev/kvm
Теперь доступ останется только у root. Учтите один момент: если какие-то ваши легитимные службы виртуализации работают не от суперпользователя, они временно споткнутся. Действуйте с оглядкой на свою архитектуру.
Шаг 4. Фиксируем настройки до планового ребута
Когда-нибудь сервер всё равно придется отправить на перезагрузку — например, для полноценного обновления ядра. Чтобы наши временные настройки не слетели при старте системы, намертво зашьем их в конфиг.
Создаем новый файл конфигурации модулей:
sudo nano /etc/modprobe.d/kvm-security.conf
Прописываем туда две строчки запрета для обоих вендоров:
options kvm_intel nested=0
options kvm_amd nested=0
Сохраняем изменения и закрываем редактор.
Теперь при любом следующем запуске хоста вложенная виртуализация гарантированно останется выключенной по умолчанию.
