Contents [show]
1. Acerca de la vulnerabilidad de Zombieload / MDS
2. Programa de lanzamiento de parches

Acerca de la vulnerabilidad de Zombieload / MDS

Las vulnerabilidades se están volviendo como celebridades, con nombres extraños y sus propios sitios web.

Los últimos en salir a escena son Zombieload, RIDL y Fallout, también conocido como muestreo de datos de microarquitectura, (MDS para abreviar), descubierto por Intel e investigado por departamentos academicos en instituciones centradas en la seguridad en todo el mundo. Estas vulnerabilidades están en la misma línea que Specter y Meltdown, y son defectos de diseño que revelan datos. Zombieload es particularmente preocupante porque afecta a todas las CPU Intel Core y Xeon fabricadas desde 2011.

Hay cuatro registros distintos de vulnerabilidades que se combinan para hacer posible una explotación de Zombieload: CVE – 2018 – 12126, CVE – 2018 – 12127, CVE – 2018 – 12130, y CVE – 2019 – 11091. Mira los códigos y verás que tres se registraron el año pasado. El tema se ha mantenido en secreto, una práctica conocida como Divulgación coordinada, para que los 'malos actores' exploten las vulnerabilidades antes de que el resto de nosotros podamos defendernos contra ellos. microsoft, Amazon AWS y Google Todos han mitigado el problema en sus centros de datos, al estar en el "círculo interno" de las empresas que se benefician de la notificación anticipada de tales problemas. Cualquier otra persona tiene que esperar una actualización de su proveedor de sistema operativo.

KernelCare comenzó a probar parches en vivo para MDS el viernes, mayo 17, y ahora están Desplegado para todas las distribuciones principales., con otros en breve para seguir. Para las últimas noticias, síguenos en @KernelCare.

Mire el video con información sobre MDS de Igor Seletskiy a continuación, o desplácese hacia abajo para obtener instrucciones sobre cómo mitigar la vulnerabilidad de MDS / Zombieload sin necesidad de reiniciar.

Nueva llamada a la acción

Cómo mitigar la vulnerabilidad de MDS / Zombieload

Si está ejecutando en hardware:

Para mitigar esta vulnerabilidad, deberá seguir los pasos de 3 que requieren no reiniciar Si sigues las instrucciones a continuación:

Paso 1: Actualizar Microcódigo sin reiniciar

El microcódigo es el código que se ejecuta dentro de la propia CPU y es manejado por Intel. La actualización del microcódigo generalmente se realiza al reiniciar: usted obtiene el nuevo kernel, tendrá un nuevo microcódigo y cuando el kernel se inicie, instalará un nuevo microcódigo en la CPU. Puede actualizar microcódigo sin reiniciar usando nuestras instrucciones.

Paso 2: Deshabilitar Hyperthreading sin reiniciar

Si no desactivas el subprocesamiento múltiple simultáneo (SMT) de la CPU, todavía tendrás un problema de que el atacante puede leer los datos de la misma CPU. Con KernelCare puede deshabilitar Hyperthreading sin reiniciar usando nuestras instrucciones.

Paso 3: Aplicar parches KernelCare

Incluso si ha realizado los pasos 1 y 2, aún debe actualizar el Kernel de Linux para asegurarse de que el usuario local no pueda leer los datos que está ejecutando en la CPU. Con KernelCare puede hacer eso sin reiniciar. Regístrese para la prueba gratuita de 30-day.

Si está ejecutando en una máquina virtual:

Solo necesitas parchear el Kernel de Linux dentro de la VM. Asegúrese de que su nodo host también se actualice, lo que normalmente realiza su proveedor de servicios.

Si está utilizando KernelCare, KernelCare le entregará los parches automáticamente y no necesita hacer nada adicional. Si no, este es el momento adecuado para Regístrese para la prueba gratuita de 30-day.

Programa de lanzamiento del parche de vulnerabilidad de MDS / Zombieload

Actualizado lunes, mayo 27

El calendario de lanzamiento de parches de KernelCare se muestra a continuación. Los horarios de lanzamiento están sujetos a cambios. Consulte aquí regularmente o póngase en contacto con nuestro servicio de asistencia.

Lanzado a producción:

  • 6 CentOS
  • CentOSPlus para CentOS 6
  • 7 CentOS
  • CentOSPlus para CentOS 7
  • CloudLinux OS 6
  • Cloud Linux 6 híbrido
  • CloudLinux OS 7
  • Debian 8
  • Debian 9
  • Ubuntu 14.04 LTS (Trusty Tahr)
  • Ubuntu 16.04 LTS (Xenial Xerus)
  • Ubuntu 18.04 LTS (Bionic Beaver)
  • Oracle Enterprise Linux
  • Oracle Enterprise Linux 6
  • Oracle Enterprise Linux 7
  • Oracle UEK 3
  • Oracle UEK 4
  • Oracle UEK 5
  • OpenVZ
  • Proxmox VE
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Amazon Linux 1
  • Amazon Linux 2

Los parches del feed de producción se aplicarán automáticamente.

comentarios 43

  1. ¿Por qué Igor Seletskiy insiste en ser la voz, nadie puede entender la palabra que dice? Entendemos que él está detrás del comienzo de esto, ¡pero FFS consigue a alguien que pueda ser la voz en estos videos!

    1. Hola mío, esta es Aleksandra Mitroshkina, Gerente de marketing de productos de KernelCare.
      Lamento que haya tenido que experimentar dificultades para entender al hablante. Trabajaremos en la voz en off para ofrecerle un contenido más comprensible en el futuro. Muchas gracias por tus comentarios!

    2. Interesante, ya que no tengo problemas para entenderlo y soy un neoyorquino. Tengo pocos amigos con acentos similares y no tengo habilidades especiales de lenguaje. Encuentro a Igor increíblemente bien informado y un orador muy interesante. Me decepcionaría perder su voz.

    1. Hola Andre, no estoy seguro de que te refieras a parches o guías prácticas, así que responderé a ambas. Ahora estamos en la fase de prueba con parches. Para algunas distribuciones, los parches deben ser a principios de la próxima semana.
      En cuanto a las Guías de procedimientos que se mencionan en un video y una publicación de blog, las publicaremos tan pronto como los primeros parches estén en producción.

    1. Hola Max, estamos probando los parches ahora.
      Planeamos comenzar a entregar parches a principios de la próxima semana.
      Estén atentos para las actualizaciones.

    1. Hola Arthur, gracias por tu pregunta.
      Sí, tenemos esto en la tubería. Sigue nuestros canales de redes sociales para mantenerte actualizado.

    2. Hola Arthur, me temo que, debido a la falta de comunicación interna, te he proporcionado la información incorrecta sobre nuestros planes futuros sobre el soporte de OpenVZ 7 de KernelCare. No estamos planeando apoyar esta distribución.

  2. Si tengo el sistema operativo cloudlinux con kernelcare en mi servidor, ¿esto se actualizará con el cuidado del kernel? ¿O necesito hacer algo manualmente?

    1. Hola Donovan, deberá realizar la actualización de microcódigo y la desactivación de SMT. Pero antes de hacer eso, diagnostica tu vulnerabilidad usando la guía en este aqui por CloudLinux OS Team.

      Cuando realice la actualización de mictocódigo y la desactivación de SMT (sabrá si necesita deshabilitarla en el enlace anterior) KernelCare entregará automáticamente los parches de Kernel de Linux, sin reiniciar.

      1. Básicamente, si no has reiniciado en algún tiempo, esto no funcionará, porque estos no existen:
        / sys / devices / system / cpu / vulnerabilidades

  3. ¿Por qué una actualización del kernel solo funciona para máquinas virtuales? No es un hipervisor actualizado y es necesario reiniciarlo. También vi paquetes qemu actualizados para la bandera md-clear.

    1. Hola Stefan, también funciona para nodos duros, pero necesitas actualizar el microcódigo y desactivar SMT, entonces los parches se aplicarán automáticamente, y sin reiniciar, si usas KernelCare.

        1. Hola Stefan,
          Bueno, md-clear en qemu es un poco en cpuid para la información del invitado.
          El kernel parcheado activará la protección en cualquier caso.

  4. ¿Es posible que le preguntes a CloudLinux upstream (CentOS, supongo?) Cuando actualizarán microcode_ctl con los últimos microcódigos que parchearán las CPUs E5 v4, por ejemplo? Los parches han estado fuera durante aproximadamente una semana, pero no hay actualizaciones para el paquete microcode_ctl

    Alternativamente, CloudLinux puede incluir un paquete actualizado que contenga 20190514 y no 20190507. De esta manera, nosotros que ejecutamos las CPUs v4 y v3 también pueden ser parcheados.

      1. Hola Alexandra,

        El paquete microcode_ctl suministrado por CloudLinux y por CentOS contiene los microcódigos 20190507 y no 20190514 (que es el más reciente).

        20190514 presenta algunas nuevas versiones de microcódigo desde 20190507:

        VLV C0 6-37-8 / 02 00000838 Atom Z series
        VLV C0 6-37-8 / 0C 00000838 Celeron N2xxx, Pentium N35xx
        VLV D0 6-37-9 / 0F 0000090c Atom E38xx
        CHV C0 6-4c-3 / 01 00000368 de la serie Atom X
        CHV D0 6-4c-4 / 01 00000411 de la serie Atom X
        BDX-ML B0 / M0 / R0 6-4f-1 / ef 0b00002e-> 00000036 Xeon E5 / E7 v4; Core i7-69xx / 68xx
        DNV B0 6-5f-1 / 01 00000024-> 0000002e Serie Atom C

        1. Hola Lucas, tienes razón, en este momento el paquete microcode_ctl suministrado por CloudLinux y por CentOS solo contiene el microcódigo 20190507, no 20190514. La razón detrás de esto es que generalmente seguimos las actualizaciones de RHEL / CentOS. Tan pronto como este microcódigo aparezca en el flujo ascendente, lo proporcionaremos para CloudLinuxOS.

      2. Ese manual de actualización de microcódigo es solo para RHEL7. No es correcto para CL6 ...

        stat: no puede stat `/ usr / libexec / microcode_ctl / update_ucode ': No existe tal archivo o directorio

        stat: must stat `/ sys / devices / system / cpu / microcode / reload ': No existe tal archivo o directorio

        1. Hola Deyan, ¡gracias por traerme esto a mi atención! Estamos trabajando en arreglar la documentación ahora. Por favor, acepta mis disculpas por el inconveniente. Te mencionaré en los comentarios cuando lo arreglemos.

      3. En la CPU Intel (R) Xeon (R) E5-2640 v4 @ 2.40GHz el servidor ejecuta CL7 y SMT desactivado con # echo off> / sys / devices / system / cpu / smt / control
        Microcódigo y kernel actualizados con #yum actualizan microcode_ctl && yum instalan kernel-3.10.0-962.3.2.lve1.5.25.8.el7
        Servidor reiniciado.
        # cat / sys / devices / system / cpu / vulnerabilities / mds devuelve lo siguiente;
        Vulnerable: se intentaron borrar los búferes de la CPU, sin microcódigo; SMT deshabilitado

        1. INCORRECTO, POR FAVOR DESPRENDA ESTO: Hola Paul, necesitas actualizar el microcódigo real como se describe aquí, actualizar el paquete microcode_ctl no es suficiente

          1. Hola Alexandra, eso no es cierto. Ese manual es solo para actualizar el microcódigo sin reiniciar. El reinicio siempre debe aplicar un nuevo microcódigo, pero parece que esto no ocurre después de la última actualización del paquete microcode_ctl, por lo que "/ sys / devices / system / cpu / vulnerabilities / mds" siempre devuelve "no microcode", incluso cuando el microcódigo se aplica manualmente .

          2. Hola Deyan, ¿puedes crear un ticket para nuestro equipo de soporte? aquí. Mis colegas podrán profundizar en los detalles técnicos de su caso y evitaremos los comentarios. ¡Gracias!

          3. Creo que mi post no se entendió bien. ¿Quiere decir que ahora está presionando el paquete microcode_ctl 20190514 (que es el más reciente) y es compatible con las CPU E5 v4?
            Lucas Rolff preguntó cuándo apoyaría lo mismo, y preguntó qué error estaba recibiendo al intentar aplicar 20190507. En su respuesta a él, confirmó que el paquete microcode_ctl suministrado por CloudLinux y por CentOS en este momento solo contiene el microcódigo 20190507, no 20190514 que admite CPUs E5 v4. Entonces, como ahora, aquellos de nosotros que usamos CPUs E5 v4 no hemos corregido porque el microcódigo 20190507 que ha suministrado no funciona para las CPUs E5 v4.

            Ya que le habías pedido a Lucas el error y él no te lo dio. Procedí y lo hice. Pero creo que su respuesta me ha indicado una dirección diferente.

          4. Paul, Lucas, Deyan, lamento informarle mal. Tenemos que esperar a que el microcódigo 20190514 esté disponible desde el principio. Lo lanzaremos en el sistema operativo CL poco después.

    1. Hola Richard, estamos trabajando para pasar estos a la producción pronto.
      Actualizará la publicación y la anunciará en nuestra página de Facebook cuando esté lista.
      Por favor acepte mis disculpas por cualquier inconveniente causado por el retraso.

    1. Hola Andre, el equipo de KernelCare está trabajando en el parche para CL7. Pedimos disculpas por cualquier inconveniente que este retraso pueda causar y esperamos su comprensión.

      1. ¿Alguna explicación para este largo retraso? ¿Es el parche más complicado o problemático en CL7? Habría esperado que el parche para su propio sistema operativo tuviera prioridad.

    1. Hola Sumesh, gracias por tu pregunta. Estamos trabajando activamente en estos parches. La ETA será conocida mañana. Recibirás la notificación en nuestros canales sociales.

  5. ¿Alguna noticia sobre microcódigo? Mis máquinas siguen siendo vulnerables:

    [root @ hotspare ~] # cat / sys / devices / system / cpu / vulnerabilities / mds
    Vulnerable: se intentaron borrar los búferes de la CPU, sin microcódigo; SMT deshabilitado

    procesador: 15
    vendor_id: GenuineIntel
    Familia CPU: 6
    modelo: 45
    nombre del modelo: Intel (R) Xeon (R) CPU E5-2690 0 @ 2.90GHz
    paso a paso: 7
    microcódigo: 0x714
    cpu MHz: 1199.896
    tamaño de caché: 20480 KB

      1. Para otras personas que tienen este problema: el microcódigo no está disponible para todos los procesadores, por lo que es posible que no tenga suerte. Compruebe / sys / devices / system / cpu / vulnerabilities / mds para asegurarse de que está protegido.

XHTML: Puedes usar estas etiquetas: <a href="" title=""> <abbr title = ""> <acronym title = ""> <b> <blockquote cite = ""> <cite> <code> <del datetime = ""> <em > <i> <q cite = ""> <s> <strike> <strong>

¿Alguna Pregunta?

Si desea programar una demostración de KernelCare, tiene preguntas o tiene preguntas de prueba y ventas, llámenos al +1 (800) 231-7307, correo electrónico sales@cloudlinux.com, o rellena este formulario.