Como remediar Spectre y Meltdown en ambientes de vSphere / VMware.


La última semana se ha hablado mucho de Spectre y Meltdown, vulnerabilidades de procesadores modernos que cuando son explotados, permiten que programas puedan obtener información que otros programas han almacenado en memoria como passwords, emails, fotos y otra información personal que normalmente no deberían poder ser accedidos por otros procesos corriendo en el mismo servidor…..hasta ahora.


Puedes leer más acerca de Spectre y Meltdown aquí: https://meltdownattack.com/

Estos bugs están catalogados bajo CVE-2017-5753, CVE-2017-5715 y CVE-2017-5754 (Spectre y Meltdown)

Estas variaciones de bugs han sido categorizadas como unas de las más grandes y masivas para la industria ya que afecta procesadores generados en la última década, es decir, millones de sistemas en todo el mundo, desde computadores personales, celulares y servidores en la nube, estos últimos considerados los más susceptibles ya que en la mayoría de los casos son compartidos por diferentes clientes and ambientes virtualizados. 


A pesar de que ciertas fuentes conocían esta vulnerabilidad hace unos meses, el tema se hizo público el pasado 3 de Enero (Puedes leer mas aqui:  https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html) y como era de esperarse, se convirtió en urgencia para compañías de hardware y software desarrollar parches para remediar en lo posible dichas vulnerabilidades. Aunque inicialmente se escuchó que habría que reemplazar cada uno de los procesadores físicos, lo cual sería algo que tomaría años; rápidamente, la combinación de actualizar todos los componentes en los servidores (BIOS/CPU Microcode, Hypervisor, VM Guest e incluso versión de hardware en el caso de VMware) al parecer serían suficientes para estar protegido. A juzgar por los blogs y documentos oficiales, al menos de VMware, si se actualizan todos los componentes, se estará a salvo - Esperemos que así sea.

Aquí dejo descripción de los diferentes pasos requeridos al día de hoy, si buscas remediar tu ambiente de vSphere:



1) Actualizar vCenter Server a las siguientes versiones; dependiendo cual de las ultimas 3 aún bajo soporte uses:
     vCenter 5.5 U3g

        2) Actualizar los hosts ESXi a las siguientes versiones:

  ESXi 5.5
 ESXi550-201801401-BG  - Este parche actualiza el Hypervisor-Assisted Guest Mitigation (el cual es necesario para que al después de aplicar updates de los sistemas operativos dentro de tus VMs, las nuevas características de la CPU del host puedan ser vistas y correctamente utilizadas por las máquinas virtuales) y CPU Microcode que esencialmente reemplaza parte de código BIOS para el CPU pero no reemplaza el BIOS por completo.
  ESXi 6.0
ESXi600-201801401-BG – Este parche corrige el Hypervisor-Assisted Guest Remediation
ESXi600-201801402-BG – Mientras este, trae los cambios necesarios para el Microcódigo de CPU
  ESXi 6.5
ESXi650-201801401-BG – Este parche corrige el Hypervisor-Assisted Guest Remediation
ESXi650-201801402-BG – Mientras este, trae los cambios necesarios para el Microcódigo de CPU
Los bundles que actualizan Microcódigo del CPU son opcionales y dependerá de si ya aplicaste el BIOS completo que debe ser proveído por la compañía de hardware.
    
     3) Asegurarse que todas tus máquinas virtuales están usando Versión de Hardware 9 como mínimo, de lo contrario, las nuevas características de CPU proveídas por el parche de ESXi no tendrá efecto y tus máquinas no estarán protegidas.


     4) El siguiente paso es instalar los parches para tus sistemas operativos que cubran vulnerabilidad CVE-2017-5715. Estos suministrados por Microsoft, RedHat, etc.  


     5) Por último, necesitaras apagar y reiniciar tus VMs, full power cycle. Bien sea después de actualizar la versión de hardware (9 como mínimo) o después de moverlas a hosts ya actualizados.



Algunas notas para resaltar y tener en cuenta:



El vCenter Server Appliance (VCSA) obtendrá un update que cubrirá su propio sistema operativo; así que es recomendado estar pendiente de cuándo saldrá. La información será actualizada aquí: https://kb.vmware.com/s/article/52264

Si tus ESXi hosts no fueron actualizados con los parches ESXi550-201801401-BG, ESXi600-201711101-SG o ESXi650-201712101-SG que fueron publicados el pasado mes y detallados en el Security Advisory VMSA-2018-0002 (https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html), podrás omitirlos y simplemente instalar los nuevos; estos updates son acumulativos.

Si tienes maquinas virtuales que no están a nivel de virtual hardware 9, las nuevas características agregadas al CPU no serán presentadas y así hayas aplicado updates del sistema operativo, estas no se harán efectivas hasta que TODO este actualizado; de lo contrario tus VMs estarán desprotegidas.

La versión de Hardware de cualquier Virtual Appliance (sean de VMware o terceros) no deben ser actualizadas manualmente; debes esperar que las nuevas versiones sean suministradas y vengan con versión 9 o mas alta.   

Si actualizas el sistema operativo antes de aplicar los parches de ESXi (Hypervisor-Assisted Guest Mitigation) las VMs requerirán ser apagadas e iniciadas de nuevo.

Si tienes curiosidad, el update a vCenter solo modifica código, no hace cambios a la base de datos y es muy rápido de aplicar.

Recuerda que así instales el CPU Microcode que VMware suministro, debes instalar el BIOS completo cuando este este disponible ya que actualizara todos los componentes del BIOS.



===========================

Comparte, pregunta, agrega o reta mi opinión aquí expuesta. Seria genial escuchar opiniones de quienes lean y ojala se beneficien de esta información; tambien de quienes puedan estar en desacuerdo. 


Recuerda que la información aquí presentada, como en cualquier área de mi blog, es mi opinión y no representa la de mi empleador.






2 comments:

  1. Hola Jorge. En mi caso tengo vSphere 5 y no me es posible realizar una migracion a 5.5 , 6 o 6.5 .Si solo actualizara el microcodigo de cpu del hypervisor y el OS de los guests, estaria libre de estas vulnerabilidades, especialmente la de VM accediendo a datos de otra VM?

    ReplyDelete
    Replies
    1. Hola Jaime,

      Como tal vez lo sabes, vSphere 5 no tiene mas soporte y en este caso por lo que entiendo, si tus hosts usan procesadores que estan dentro de la lista de CPUs afectados, no estaras del todo a salvo, lastimosamente.

      Delete