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.
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.
Aquí dejo descripción de los diferentes pasos requeridos al día de hoy, si buscas remediar tu ambiente de vSphere:
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:
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.
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.
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.
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?
ReplyDeleteHola Jaime,
DeleteComo 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.