Parchea VENOM sin reiniciar QEMU

Seguro que ya os habéis enterado... Los investigadores de CrowdStrike han descubierto una nueva vulnerabilidad que han bautizado como VENOM (Virtualized Environment Neglected Operations Manipulation) que permite a un atacante acceder al datastore (disco físico) de una máquina virtual. Concretamente la vulnerabilidad con CVE-2015-3456 se trata de un desbordamiento de buffer que afecta a la emulación del viejo Floppy Disk Controller (FDC) que implementan los hipervisores KVM/QEMU y Xen.

Imaginar lo que significa: tenemos contratado a un proveedor un servidor virtual en la "nube" que comparte la misma máquina física con otros servidores de otros clientes. Todos los datos de esa máquina física podrían ser robados... Urge entonces parchear lo antes posible, pero ¿es posible implementar un parche sin reiniciar los procesos qemu que ya están ejecutándose?

Según leemos en VenomFix se puede conseguir en casi todos los casos utilizando comandos virsh, una herramienta en línea de comandos para administrar a los huéspedes y al hypervisor. De esta manera no es necesario el reinicio completo y se parchea cada instancia con sólo un pequeño bloqueo de unos segundos. ¡Proveedores de VPS tomad nota!

El primer paso es actualizar o asegurarse de que ya se ha parcheado la versión de qemu. En Redhat/CentOS sería qemu-kvm-0.12.1.2-2.448 o posterior. Esto se puede lograr simplemente actualizando la distro ya que la mayoría ya lo han liberado a través de su gestor de paquetes.

El siguiente paso es guardar todas las instancias en /dev/shm (RAM) y restaurarlas a un estado de ejecución. Las instancias se bloquearán durante un breve tiempo y volverán a su estado normal. Antes de ejecutar el siguiente comando hay que asegurarse de que tenemos suficiente espacio en memoria o cambiar /dev/shm o disco:

for i in $(virsh list --all | grep running | awk '{print $2}') ; do instance=$i ; date ; time virsh save $instance /dev/shm/$instance ; date ; time virsh restore /dev/shm/$instance ; date ; rm -f /dev/shm/$instance ; done

Podremos confirmar que el proceso usa el nuevo binario viendo el cambio de inodo:

Nota:
Las instancias guest de QEMU KVM que están usando huge pages Anónimas (transparentes) obtendrán un error 'alloc_mem_area: can't mmap hugetlbfs pages'. Para solucionarlo primero debemos salvar la instancia ('virsh save') y luego fijar el tamaño de las páginas con:

# echo 4096 > /proc/sys/vm/nr_hugepages

Pero ojo que no se pueden combinar HugePages fijadas con KSM (Kernel Same-Page Merging)... más información en:

http://www.venomexploitfix.com/