Remediar Spectre y Meltdown en ambientes vSphere - Nueva información

A principio de este año cuando la industria estuvo en llamas de fuego, particularmente Intel, al hacerse público las vulnerabilidades Spectre y Meltdown; todo el mundo pensó que estábamos a punto de pasar por el peor año en la industria y que necesitaríamos remplazar los procesadores físicos de la mayoría de los servidores en nuestros datacenters porque se decía que no había solución sistemática que pudiera corregir los problemas. 

La segunda y tercer semana de Enero fueron de especulaciones. Cuando finalmente Intel lanzo los parches de una manera afanada, muchos corrimos a instalarlos en un afán jamás visto – vi como en 4 días se actualizaban cientos de servidores cuando normalmente se tomaban meses.  Todo esto por la sensación de urgencia que se había generado, quizás sin tanta razón, puesto que no se supo de ataques mayores.

Yo escribí un blog post con los pasos que en aquel momento eran requeridos para actualizar ambientes vSphere; ese resumen era lo recomendado y muchos los sugirieron completar rapido. Días después se supo que el microcódigo  incluido estaba causando problemas y entonces la recomendación siguiente fue: No hacer nada y esperar, o en caso de ya haber aplicado los parches, hacer una modificacion manual en cada host bajo /etc/vmware/config

Cerca de 2 meses después, Intel ha entregado nuevos parches de microcódigo, los cuales hoy han sido lanzados por VMware y cuya informacion completa se encuentra en VMSA-2018-0004.03

Esta es la nueva información a seguir para remediar tu ambiente vSphere, en este orden: 

1. Actualizar tu vCenter Server a las siguientes versiones:

          6.5 U1g
          6.0 U3e
          5.5 U3h


2. Instalar ambos parches en tus hosts ESXi, dependiendo cual versión utilices:

        ESXi 6.5: ESXi650-201803401-BG y ESXi650-201803402-BG
        ESXi 6.5: ESXi600-201803401-BG y ESXi600-201803402-BG
        ESXi 5.5: ESXi550-201803401-BG y ESXi550-201803402-BG


Los bundles ***3402-BG son los que contienen el microcódigo; los ***3401-BG instalan los requisitos para que los Guest VMs puedan usar los nuevos mecanismos de CPU presentados.

3. Si aún no lo has hecho, aplicar los parches de los sistemas operativos en tus maquinas virtuales - bien sean Linux o Windows, el proveedor debe ya haber lanzado estos parches. 


Ciertos detalles a tener en cuenta:

  • Si después de aplicar los parches que salieron mal, tuviste que implementar la solución alternativa de modificar /etc/vmware/config, estos parches harán la ‘limpieza’ de esa modificación, Pero, ten presente que si usas Host Profiles o AutoDeploy, habrá que verificar que no se re-aplique dicho cambio por error.
  • Los parches de sistema operativo en las VMs no son opcionales para protegerse; de no actualizar el OS en tus VMs, no estarás cumpliendo con todos los requisitos y la remediación quedara a medias.
  • La nueva actualización para vCenter es necesaria para EVC, aun si no usas EVA en tus clúster, es recomendable aplicarlo – aunque no requerido para estar protegido.
  • Ambos parches de los hosts pueden ser instalados conjuntamente y solo necesitaras reiniciar una vez.
  • Recuerda que la versión de Virtual Hardware de tus VMs debe ser 9 minimo, pero 11 es recomendable. Si usas Virtual Appliances y no estan en version 9, no la actualices manualmente, debes esperar por la nueva version, completa.
  • La lista de procesadores para los cuales hay microcódigo la puedes ver en la tabla en https://kb.vmware.com/s/article/52085
  • Ten presente que asi apliques los parches, incluyendo el microcódigo, es recomendable instalar el BIOS completo una vez el proveedor de hardware lo haga disponible. 
  • 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.

El mismo KB52085 contiene los pasos para confirmar que tus hosts tienen ambos parches requeridos, pero acá los dejo igual:
           Enciende una VM de versión de hardware 9 o mas alta y examina en su archivo vmware.log para verificar que alguna de las siguientes líneas existe:

            “Capability Found: cpuid.IBRS”
            “Capability Found: cpuid.IBPB”
            “Capabliity Found: cpuid.STIBP”

Con encontrar una sola de las 3 anteriores lineas, indicara que ambos parches han sido instalados.



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


Si tienes preguntas, dudas o deseas agregar/compartir algo, te invito a interactuar conmigo en Twitter o dejar tu mensaje en los comentarios.

Gracias por leer y compartir este post. :-)






3 comments:

  1. Gracias Jorge
    Después de actualizar el VCSA 6.5 a la última versión, actualizar los ESX con los parches de Marzo y actualizar las VMs con los últimos parches de seguridad y vHW 13, siguen sin aparecer alguna de las tres CPUID. ¿Se te ocurre a qué puede ser debido?

    El caso es que los ESX sí indican que los nuevos microcódigos están presentes (he usado un script que lo chequea), pero al hacer la comprobación en los vmware.log de las máquinas virtuales, no aparecen

    Lo único que no he hecho es actualizar la BIOS de los Blade HP donde están los ESX, pero se supone que con la actualización de VMware debería de servir ¿no?

    Muchas gracias de antenamo y saludos cordiales

    ReplyDelete
    Replies
    1. Hola David,
      Muchas gracias por referenciar este post y por tu pregunta. Se me ocurre... ya aplicaste parches del Sistema Operativo a tus VMs y/o las apagaste y reiniciaste por completo??
      Si te falta eso, hazlo y nos cuentas si el resultado cambia.

      Tienes razon que el no haber instalado aun el nuevo BIOS de HPE, no implicaria que no pudieras validar CPUID. El Microcodigo proveido por VMware tendria que funcionar, PERO, recuerda que de todas maneras es recomendado aplicar BIOS cuando este disponible ya que actualiza mas que el Microcodigo.

      Delete
    2. Muchas gracias Jorge. Sí, aplique parches de sistema operativo con reinicio y nada de nada. Voy a probar a actualizar el firmware de HP y te cuento si consigo algo.
      Saludos y enhorabuena por el blog

      Delete