День VENOM: координируем патчинг KVM и Xen-хостов в нескольких организациях

Две недели назад мы писали про VENOM в режиме «получили информацию, начали патчить до публичного анонса». Сейчас, когда первая волна прошла и публичный анонс CVE-2015-3456 уже на подходе, можно рассказать как процесс выглядел изнутри - без паники, зато с реальными шишками.

Масштаб задачи

У нас несколько организаций на сопровождении, и KVM с Xen стоит примерно у половины. Это не единый кластер под одним управлением - это отдельные инфраструктуры с разными администраторами на стороне клиента, разными политиками maintenance-окон и разной степенью готовности «вот сейчас и перезапустим».

Первый шаг везде одинаковый - инвентаризация. На каждом хосте смотрим версию QEMU и список запущенных доменов:

# RHEL/CentOS
rpm -q qemu-kvm

# Debian/Ubuntu
dpkg -l | grep qemu-kvm

# Запущенные домены
virsh list --all

После этого картина раскладывается на три категории: хосты с патчем (дистрибутив уже выкатил, достаточно yum update/apt-get upgrade и согласовать перезапуск VM); хосты без патча в репозитории (Debian Wheezy, отдельные CentOS 6 с устаревшими зеркалами - нужно либо ждать, либо брать пакет из security-репозитория вручную); и хосты с Xen, где QEMU живёт отдельным пакетом и просто apt-get upgrade qemu-kvm ничего не даст - надо явно обновлять xen-qemu-dm и аналоги.

Про live migration и неочевидный момент

Первый инстинкт был - сделать live migration VM на запасной хост с новым QEMU, не останавливая гостей. Красиво звучит, но не работает так, как хочется.

При live migration libvirt переносит состояние гостевой ОС, но процесс QEMU на целевом хосте запускается заново - с той версией QEMU, которая стоит там. То есть сам по себе migration уже является «перезапуском» QEMU - только на другом железе. Это значит, что схема работает: мигрируем VM с уязвимого хоста на хост с уже обновлённым QEMU, и гость оказывается под защитой. Хост-источник можно патчить дальше без спешки.

Нюанс в том, что принимающий хост должен быть обновлён до миграции, а не после. Казалось бы, очевидно - но мы видели несколько конфигураций, где на паре хостов патч поставили, VM перемигрировали туда, а потом забыли обновить хосты-источники. После выключения последних VM там всё так же торчала дырявая версия QEMU - не критично для выключенного хоста, но неприятно с точки зрения порядка.

Окна и согласование

Вот здесь самое интересное с операционной точки зрения. Технически обновить пакет несложно. Сложно - договориться с несколькими разными людьми про перезапуск продакшн-VM в нерабочее время.

Мы разбили хосты на три группы по срочности:

• Многоарендные хосты - там, где на одном KVM-хосте живут VM разных проектов или разных зон доверия. Здесь компрометация одной VM потенциально означает доступ ко всем остальным на том же хосте. Патчим в первую очередь, окно согласуем агрессивно.
• Хосты с одним клиентом - риск ниже (чтобы применить VENOM, атакующий уже должен быть внутри одной из ваших VM), но всё равно патчим в течение недели.
• Dev/staging-хосты - патч ставим немедленно, перезапуск VM без лишних согласований, они для этого и существуют.

По факту большинство продакшн-VM удалось перезапустить в первую же ночь после получения подтверждения от клиентов. Пара хостов с очень чувствительными нагрузками потребовала полноценного maintenance-window с участием команды клиента - там мы сидели вместе и делали всё по процедуре.

Флоппи в XML

Отдельная работа - проверить libvirt-конфиги XML на предмет явно включённого эмулятора флоппи. У QEMU он есть по умолчанию, но в XML домена он прописывается явно только если кто-то специально настраивал или клонировал конфиг с устаревшего шаблона. Смотрим:

grep -r 'floppy\|fdc' /etc/libvirt/qemu/

Там, где флоппи прописан и не нужен - убираем из конфига. Это не замена патчу, но лишний слой защиты. VM нужно остановить и запустить заново (не просто reboot гостя - а virsh destroy + virsh start), чтобы конфиг применился.

Xen отдельной строкой

На Xen немного другая картина - там QEMU используется только для HVM-доменов (аппаратная виртуализация), а PV-домены (паравиртуализация) QEMU не используют и VENOM к ним не применим. На практике у большинства клиентов HVM-домены есть - Windows-гости почти всегда HVM. Так что расслабляться не стоило.

На Debian с Xen патч шёл через xen-utils-* и отдельно qemu-utils в зависимости от версии Xen. Мы проверяли через xl info и xen-detect, потом смотрели какая именно версия QEMU используется для аппаратной эмуляции.

Итог на сегодня

Все клиентские хосты с KVM и Xen обновлены. Большинство запущенных VM перезапущены в согласованных окнах. Несколько VM, которые физически нельзя было трогать до конца этой недели, стоят в расписании - патч на хосте стоит, следующий запуск гостя уже будет с обновлённым QEMU.

Публичный анонс CVE-2015-3456 ожидается в ближайшие дни. Эксплойт в открытом доступе пока не появился, но паузу брать незачем - кто из читателей ещё не обновился, самое время.