ADG Оставить заявку
Блог Информационная безопасность 5 мин чтения

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, по имеющимся данным, ожидается в ближайшие дни. Эксплойт в открытом доступе пока не появился, но это вопрос времени. Кто не поставил патч - момент хороший.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.