VENOM: патчим QEMU на всех KVM и Xen-хостах до того, как это стало мейнстримом
CVE-2015-3456 - побег из VM через эмулятор флоппи-дисковода QEMU. Объясняем клиентам чем VENOM отличается от Heartbleed и почему патч надо ставить немедленно.
VENOM (CVE-2015-3456) - критическая уязвимость в эмуляторе флоппи-дисковода QEMU, позволяющая выйти за пределы виртуальной машины
На этой неделе к нам попала информация о CVE-2015-3456, которую исследователи из CrowdStrike назвали VENOM. Публичного анонса ещё нет - широкая огласка ожидается позже, - но деталей достаточно, чтобы начать действовать прямо сейчас. Мы так и сделали.
Что такое VENOM
VENOM - это переполнение буфера в контроллере флоппи-дисковода внутри QEMU. Да, именно флоппи. Эмулятор флоппи-дисковода, который присутствует в QEMU по умолчанию и включён даже там, где никакого физического или виртуального флоппи никто никогда не подключал.
Уязвимость позволяет коду, исполняемому внутри гостевой ОС, записать специально сформированные данные в регистры FDC (Floppy Disk Controller) и выйти за пределы виртуальной машины с привилегиями процесса QEMU на хост-системе. Если QEMU запущен от root - а в ряде конфигураций KVM он именно так и запускается - это root на гипервизоре. Дальше объяснять не надо.
Затронуты: QEMU, Xen (использует QEMU для аппаратной эмуляции), KVM (через libvirt + QEMU). VMware и Hyper-V на этот раз в стороне - у них своя реализация эмуляции устройств.
Почему мы патчим до анонса
У нас есть несколько источников, которые дают информацию о критических уязвимостях с опережением публичного раскрытия. Когда информация достаточно конкретна - CVE-номер, описание вектора, затронутые компоненты - мы не ждём публикации в новостях. Цена ожидания очевидна: патч всё равно придётся ставить, только в ситуации большей неопределённости и с меньшим временем до появления эксплойтов в открытом доступе.
Для клиентов на сопровождении это выглядит так: они получают уведомление «обнаружена критическая уязвимость в компоненте X вашей инфраструктуры, согласуем окно для патчинга» - и мы уже едем, не дожидаясь пока это попадёт на первые полосы.
Что мы сделали
Инвентаризация первична. Нужно понять, на каких хостах QEMU вообще стоит и в какой версии. На CentOS/RHEL:
rpm -q qemu-kvm qemu-img
На Debian/Ubuntu:
dpkg -l | grep -E 'qemu-kvm|qemu-system'
Дальше - обновление. На RHEL/CentOS патч уже доступен через стандартные каналы:
yum update qemu-kvm
На Debian Wheezy (и Jessie, который вот-вот выходит) - через apt-get update && apt-get upgrade qemu-kvm. На системах с Xen проверяем отдельно пакеты xen-qemu-dm и аналоги - там QEMU может жить независимо от системного пакета.
Важный нюанс: обновление пакета не означает, что запущенные виртуальные машины автоматически защищены. QEMU - это процесс, который запускается для каждой VM. Чтобы обновлённый код заработал, нужно перезапустить VM. Live migration в этом случае не помогает - процесс QEMU при миграции не пересоздаётся на той же версии.
Мы прошли по всем клиентским хостам, согласовали окна и перезапустили VM там, где это было критично. Там, где перезапуск нельзя было сделать немедленно - хотя бы убедились, что патч установлен и следующий старт VM подхватит новый QEMU.
Отдельно проверили, включён ли флоппи в конфигурации VM. Для большинства современных гостей он не нужен. В libvirt XML профиле виртуальной машины контроллер флоппи выглядит как <controller type='fdc'> или устройство <disk type='file' device='floppy'>. Если его нет и он не нужен - можно явно отключить в конфиге домена, это дополнительная линия защиты на случай если патч по какой-то причине не попал или не применился.
Разница с Heartbleed - что объяснять клиентам
Неизбежно пошли звонки с вопросом «это как Heartbleed?». Объясняем разницу, потому что она принципиальная.
Heartbleed - это утечка данных. Атакующий мог читать оперативную память процесса OpenSSL: ключи, сессионные данные, пароли. Он читал, но не исполнял код на сервере. Затронуты были внешние публичные сервисы с HTTPS - любой сервер, торчащий в интернет с уязвимым OpenSSL.
VENOM - это побег из виртуальной машины. Атакующий должен сначала получить код выполнение внутри гостевой ОС - то есть уже скомпрометировать её, - и только потом пробить периметр до гипервизора. Вектор атаки проходит через слои: взлом приложения или ОС в гостевой системе, а потом эксплуатация VENOM для выхода наружу.
Итого: Heartbleed был доступен снаружи без предварительного взлома. VENOM требует более сложной цепочки, но последствия хуже - если уязвимость сработает, атакующий получает хост, а не одну VM.
Для клиентов с многоарендной инфраструктурой - там, где на одном гипервизоре живут VM разных проектов или разных зон доверия - VENOM представляет более высокий риск, чем может казаться по первому впечатлению. Это не паника, но и не «подождём, поглядим».
Состояние на сейчас
На всех хостах клиентов, которые мы сопровождаем и где используется KVM или Xen, патч установлен. Большинство VM перезапущены или поставлены в очередь на перезапуск в ближайшее плановое окно. Конфигурации XML проверены на наличие явно включённого флоппи - в нескольких местах убрали ненужный контроллер.
Публичный анонс CVE-2015-3456, по имеющимся данным, ожидается в ближайшие дни. Эксплойт в открытом доступе пока не появился, но это вопрос времени. Кто не поставил патч - момент хороший.