Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
Ya están aquí los parches KernelCare+ para CVE-2020-1971
8 de diciembre de 2020 - Equipo de RRPP de TuxCare
Grandes noticias del equipo de OpenSSL: han publicado la corrección de una nueva CVE-2020-1971 que provoca interrupciones en los servidores a través de los campos del certificado x509v3. La buena noticia es que no puede provocar el robo de datos; sin embargo, tiene la capacidad de apagar sus servidores y paralizar los flujos de funcionamiento de la empresa. Las versiones OpenSSL 1.1.1 y 1.0.2 están afectadas por este problema. Otras versiones de OpenSSL son sin apoyono se han comprobado y es muy probable que el vendedor no las solucione.
En este momento, el equipo de KernelCare está realizando un delicado trabajo de portar los parches del proveedor 1.1.1 a v.1.1.0 y enriquecerlos con la tecnología de parcheo en vivo. Los parches sin reinicio para las versiones soportadas y no soportadas de OpenSSL se entregarán en 24 horas para CentOS6, y 7 con los parches para el resto de distribuciones soportadas publicados a finales de esta semana.
ACTUALIZACIÓN del 9 de diciembre:
Se han publicado los parches para CentOS 6 y CentOS 7. Los clientes de KernelCare empezarán a recibir las actualizaciones en las próximas 4 horas.
Para mitigar riesgos adicionales, mañana publicaremos una nueva versión del agente KernelCare.
Contenido:
¿Qué ha pasado?
Lo peor vino para los usuarios de CentOS6 y otras distribuciones EOL que están ejecutando versiones de OpenSSL anteriores a 1.1.1 y 1.0.2: basado en las fuentes abiertas, las versiones anteriores de OpenSSL están fuera de soporte y es seguro asumir que el proveedor no lanzará las correcciones para CVE-2020-1971 para las versiones más antiguas de la biblioteca, dejando así a los servidores empresariales susceptibles de ser cerrados por actores maliciosos. En este momento, KernelCare+ es uno de los pocos servicios que tiene los parches para CVE-2020-1971 previstos para el lanzamiento en 24 horas y puede actualizar OpenSSL antiguo y nuevo sin reiniciar el servicio ni el servidor.
Los que se quedan con los sistemas operativos o las bibliotecas compartidas que han llegado al final de su vida útil tienen varias razones constructivas para hacerlo. Admitámoslo: la migración a una nueva biblioteca compartida o sistema operativo es un asunto tedioso y costoso. E incluso si los administradores de sistemas están de acuerdo en actualizar miles de flotas de servidores, la dirección de la empresa evalúa adecuadamente la cantidad de recursos financieros y de tiempo necesarios y, por tanto, se muestra indecisa.
Entonces, ¿qué opciones tiene ahora? La más obvia - si estás usando la v1.1.x de OpenSSL - arremángate y parchea CVE-2020-1971 manualmente. Si utiliza la versión 1.0, actualícese a la versión más reciente de OpenSSL para obtener la corrección. Sea cual sea su elección, ambas requieren reiniciar el servicio o reiniciar todo el sistema para que la actualización de la biblioteca compartida surta efecto. No importa lo que elija, las consecuencias son las mismas: tiempo de inactividad y carga de trabajo adicional.
¿Cómo mitigar CVE-2020-1971 sin reiniciar el sistema?
También existe una tercera opción de actualización de OpenSSL sin migración a la versión más reciente ni aplicación manual de parches. La que no añade una carga extrema a su carga de trabajo provocada por las actualizaciones de emergencia. Deje que KernelCare+ parchee OpenSSL por usted automáticamente.
El equipo de KernelCare+ está ahora en proceso de portar los parches 1.1.1 del proveedor a v.1.1.0 y enriquecerlos con la tecnología de parcheo en vivo. KernelCare+ es una aplicación de parches en vivo para bibliotecas compartidas que aplica actualizaciones de seguridad sin afectar al estado operativo de sus aplicaciones: sin reinicios ni reinicios. Además de parchear en directo Glibc y OpenSSL, KernelCare+ protegerá también los núcleos Linux.
Los parches KernelCare se publicarán el 9 de diciembre de 2020. Primero - para las distribuciones más afectadas - CentOS 6 y CentOS 7. Los parches para el resto de distribuciones estarán disponibles en los próximos días.
Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare
Su cuarta opción es comprar un Soporte Livecycle Extendido de CloudLinux, u optar por un poderoso dúo: CloudLinux's CentOS 6 ELS y KernelCare+ Bundle de CloudLinux. El proceso de instalación es sencillo: ejecute un comando para añadir un nuevo archivo de repositorio. Después, CloudLinux le proporcionará actualizaciones de OpenSSL, Glibc, cPanel, Apache, PHP, MySQL, OpenSSH, Zlib, etc. El trabajo de KernelCare+ será proporcionarle estas actualizaciones sin reiniciar ni interrumpir sus procesos y operaciones.
Acerca de CVE-2020-1971
OpenSSL ha publicado recientemente (8 de diciembre de 2020) un parche de aviso para una vulnerabilidad de alto riesgo de desviación de puntero nulo encontrada en la función GENERAL_NAME_cmp() de la biblioteca de cifrado. Con esta vulnerabilidad sin parchear, un atacante puede enviar parámetros maliciosamente diseñados a la función GENERAL_NAME_cmp() y bloquear el sistema causando una denegación de servicio (DoS). La vulnerabilidad ha sido asignada a CVE-2020-1971.
El propósito de la función GENERAL_NAME_cmp() es doble:
- Compara los nombres de los puntos de distribución de la lista de revocación de certificados (CRL) entre la CRL disponible descargada mediante la opción "-crl_download" y el punto de distribución de CRL incluido en el certificado X.509.
- Verifica que el firmante del token de respuesta de marca de tiempo coincide con el nombre de autoridad de marca de tiempo.
Si un atacante puede controlar los dos parámetros que se comparan, puede colapsar el sistema utilizando CRL maliciosas o certificados X.509 maliciosos.
OpenSSL utiliza un tipo genérico llamado GeneralName para realizar las comparaciones. Uno de los tipos se llama EDIPartyName. Si ambos parámetros contienen el tipo EDIPartyName, el código OpenSSL lo trata como "other" y se produce un fallo de segmentación.
Todos los servidores que utilicen las versiones 1.1.1-1.1.1h y 1.0.2-1.0.2w de OpenSSL deben actualizarse a la última versión 1.1.1i o 1.0.2x. Los desarrolladores que utilicen OpenSSL como dependencia también deberían parchear la biblioteca de cifrado, especialmente si implementan las herramientas s_server, s_client y verify para certificados. Estas herramientas utilizan GENERAL_NAME_cmp() en su funcionalidad, y el investigador de seguridad de Google, David Benjamin, que encontró la vulnerabilidad probó y demostró que OpenSSL se bloqueará si se les envía una entrada malformada.
