El operador de nube francés OVH implementó un parche de emergencia en miles de servidores para corregir Januscape, una vulnerabilidad crítica de KVM que permitía el escape de máquinas virtuales al host. Para minimizar riesgos, utilizaron su centro de datos de Sídney como prueba antes del despliegue global, reiniciando hosts en olas coordinadas para evitar caídas masivas de clientes. A pesar de algunos fallos de hardware y errores de API, el CISO calificó la operación como un logro, aunque admitió la necesidad de mejorar los procesos de comunicación y soporte.

El operador de nube francés OVH ha revelado que utilizó su centro de datos de Sídney, Australia, como el "muñeco de pruebas" para testear el despliegue rápido de una solución para el error crítico de escape de invitado a anfitrión Januscape en la máquina virtual basada en el kernel de Linux (KVM).

Januscape, también conocido como CVE-2026-53359, permitía a atacantes con acceso de root a una VM invitada ejecutar código como root en el anfitrión, provocar la caída de esa máquina o tomar el control de todas las demás VMs invitadas.

Una explotación generalizada de escape de invitado a anfitrión es un escenario de pesadilla, ya que muchas nubes importantes utilizan KVM para dividir sus servidores en máquinas virtuales y luego alquilar esos invitados a los clientes. La perspectiva de que los atacantes accedan a la VM de un cliente y la utilicen para derribar otros invitados o un anfitrión completo es, por lo tanto, una violación aterradora de la promesa de los operadores de nube de ejecutar las cargas de trabajo de los clientes en un aislamiento absoluto.

Solucionarlo fue, por lo tanto, una prioridad.

El lunes, el CISO de la nube francesa OVH, Julien Levrard, reveló cómo la empresa gestionó el trabajo de parcheo de emergencia en decenas de miles de anfitriones que ejecutan aproximadamente un millón de máquinas virtuales, en una publicación extensa que ofrece un relato inusualmente detallado y sincero de cómo las nubes afrontan incidentes de seguridad graves.

Una forma de mitigar el error era desactivar la virtualización anidada creando un archivo de configuración de dos líneas en cada host que ejecutara Linux KVM. Eso no era una opción porque OVH no tiene forma de saber si sus clientes necesitan virtualización anidada y depende de ella para trasladar las VMs a diferentes anfitriones físicos.

Tampoco resultaba atractivo aplicar un parche en vivo, ya que podría introducir inestabilidad. La migración en vivo a hosts parcheados era otra opción, pero OVH la rechazó ya que el proceso es lento y la empresa sintió que podría tardar meses en trasladar toda su flota de VMs de clientes a un entorno libre de Januscape.

Por lo tanto, la empresa decidió realizar un backport de la solución Januscape en la distribución Debian que utiliza en producción y reiniciar todos los hosts, notificando a los clientes con antelación pero sin darles opción. Esto significó que los clientes que dependen de un solo host experimentarían cierto tiempo de inactividad, pero el comité ejecutivo de OVH aprobó este enfoque por tres razones:

* La necesidad de parchear antes de que ocurrieran los ataques;
* Tratar los casos individualmente significaría que la nube de OVH sería vulnerable durante más tiempo;
* El deseo de proteger al mayor número de clientes y tolerar el impacto en una minoría.

OVH también decidió mantener en secreto el plan de parcheo.

"Comunicar con más detalle durante la ejecución del plan de mitigación, mientras la infraestructura permanecía sin parchear, habría aumentado significativamente el riesgo para nuestros clientes, llevando potencialmente a algunos a 'probar' el exploit disponible públicamente", escribió Levrard.

Danger down under

Para probar su enfoque de destreza en el parcheo, OVH decidió arreglar primero su región de Sídney; una de las regiones más pequeñas de la empresa y en la cual, gracias a que la costa este de Australia está ocho horas adelantada respecto a Francia, los equipos en Europa realizan el trabajo durante sus horas laborales, pero en un momento de poca actividad en Sídney. Por lo tanto, la empresa planeó ir al hemisferio sur y aprender de la experiencia antes de desplegar la solución de forma más amplia.

El plan de OVH requería que los reinicios ocurrieran en oleadas, con un "umbral de apagado" impuesto si 15 hosts fallaban simultáneamente en regiones de alta densidad, o cinco equipos en otras regiones.

Pero esas oleadas no eran tan simples como ir rack por rack.

"El riesgo principal para nuestros clientes durante tal operación no es el reinicio en sí, sino la interrupción simultánea de múltiples instancias del mismo proyecto, asegurando una resiliencia de la aplicación capaz de manejar un fallo del proveedor", explica el blog de OVH sobre el proyecto. "Un cliente que ha distribuido sus cargas de trabajo en múltiples hosts para asegurar la alta disponibilidad no debería ver que todas sus instancias fallen al mismo tiempo. Se decidió ir más allá de la simple adhesión a las reglas de anti-afinidad que pudieran haber sido definidas en los despliegues de los clientes".

"Así, para cada proyecto de cliente con instancias distribuidas en múltiples hosts, nuestros orquestadores calculan un grafo de coubicación. En ningún momento se reinician dos hosts que ejecuten instancias del mismo proyecto en la misma ventana: se definen oleadas mutuamente excluyentes, y un host debe estar nuevamente en línea antes de que se lance el siguiente en la misma clase de anti-afinidad".

El esfuerzo de parcheo encontró algunos obstáculos. Algunas VMs no se reiniciaron después del reinicio del hipervisor. Otras experimentaron corrupción de datos durante los apagados forzados. Las APIs de OpenStack fallaron, produciendo horas de errores HTTP 503 y obligando al aplazamiento de una oleada de parcheo. En un sitio de Canadá, "el tráfico de la API alcanzó 10 veces el pico habitual, desbordando a los equipos de gestión y soporte".

Hardware hiccups

Algunos componentes de hardware murieron durante el proceso.

"En la primera noche, aproximadamente entre 20 y 30 hosts de 6,000 no se recuperaron por sí solos", reveló Levrard, culpando a "módulos de memoria defectuosos, problemas de configuración de la BIOS e interfaces de red inactivas". Algunas máquinas necesitaron baterías CMOS nuevas.

El CISO considera que el enfoque de OVH fue "una hazaña notable", ya que produjo "un número muy razonable de interrupciones e impacto en los clientes en relación con la escala del proyecto".

Pero cree que la empresa deberá mejorar.

"Reconociendo que los próximos meses podrían traer más revelaciones de vulnerabilidades del kernel, parece claro que este procedimiento de emergencia deberá repetirse", escribió. "Tendremos que hacerlo mejor la próxima vez, tanto en la gestión del impacto bruto de los reinicios como en proporcionar a los clientes avisos previos y soporte durante las operaciones".

Por lo tanto, la empresa está llevando a cabo un análisis post-mortem que espera mejore sus procesos. 

Fuente:
TheRegister