ClickCease Nueva Vulnerabilidad del Kernel Encontrada por Virtuozzo Live-Patched por KernelCare - TuxCare

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

Nueva vulnerabilidad del kernel detectada por Virtuozzo Live-Patched by KernelCare

2 de julio de 2020 - Equipo de expertos TuxCare

Nueva vulnerabilidad del kernel encontrada por Virtuozzo Live parcheada por KernelCare

Hace un mes, el equipo de Virtuozzodescubrió la nueva vulnerabilidad de seguridad en el kernel - CVE-2020-14305. Corrompe la memoria en kernels desde v3.5 a v4.10 y afecta a varias distribuciones Linux. KernelCare está preparando los parches para este CVE que estarán disponibles esta semana. Lea este artículo para saber cómo se descubrió la vulnerabilidad y cuál es la mitigación para ella.

Un CVE de corrupción de memoria (CVE-2020-14305) fue descubierto a principios de junio por el ingeniero del kernel Linux de Virtuozzo, Vasily Averin. La vulnerabilidad afecta a varias distribuciones de Linux: Red Hat Enterprise Linux 7, Debian 8 y 9, Ubuntu 14.04 y 16.04, UEK 3 y 4, Centos 7 ALT y kernels de 3.5 a 4.10. Si el puerto IPV6 1720 está abierto en el nodo, conectarse a él corrompe la memoria. Particularmente, el equipo de FastVPS - el usuario que reportó este bug al equipo de Virtuozzo - ha experimentado la corrupción de un elemento en la losa kmalloc-192. La vulnerabilidad está corregida en Virtuozzo Hybrid Server 7.0 Update14 y ReadyKernel 108.

 

Según RedHat, este problema está clasificado como de impacto moderado debido a que se limita únicamente al uso del puerto IPV6 1720 y si se utiliza un módulo concreto para voz sobre IP H.323.

Para solucionar este problema, el equipo de Virtuozzo ha creado un parche para Virtuozzo 7 y el equipo de KernelCare ha creado los parches para otras distribuciones Linux afectadas para la distribución sin reinicio.

El equipo de KernelCare quiere dar las gracias al equipo de Virtuozzo y a Vasily Averin por encontrar este fallo y darnos la oportunidad de proporcionar a nuestros clientes los parches contra CVE-2020-14305 tan rápidamente.

 

Calendario de publicación de parches KernelCare

 

Este es el calendario de publicación de los parches KernelCare:

  • Lunes 6 de julio: RHEL7, Debian8 y 9, Ubuntu 14.04 y 16.04, 
  • Jueves, 9 de julio: Unbreakable Enterprise Kernel 3 & 4, CentOS 7.

 

Instrucciones de mitigación

 

No se necesita ninguna mitigación especial para parchear esta vulnerabilidad. Si su kernel está afectado y utiliza KernelCare, los parches se aplicarán automáticamente en función de su configuración de actualización (por defecto, el agente de KernelCare busca los parches cada 4 horas).

Si estás utilizando tu KernelCare - tus parches serán entregados automáticamente por KernelCare y no necesitas hacer nada extra. Si no es así, este es el momento adecuado para suscribirte a una prueba de 30 días. No necesitas tarjeta de crédito.

 

¿Cómo se descubrió CVE-2020-14305?

El equipo de Virtuozzo ha proporcionado a KernelCare los detalles exclusivos de cómo se descubrió este CVE. Se ha hecho posible con la ayuda de su cliente - equipo FastVPS

"Quiero agradecer al equipo de FastVPS por reportar este bug, su compromiso, paciencia y colaboración en este sentido. Sin su colaboración, esta vulnerabilidad podría no haber sido descubierta", dijo Vasily Averin, ingeniero del kernel de Linux en Virtuozzo.

Siga leyendo para conocer toda la historia. 

Buscando entre los volcados de fallos, el equipo de Virtuozzo descubrió la causa de los fallos - era la corrupción de memoria en la losa kmalloc-192 donde se almacenan diferentes objetos del kernel de 128 a 192 Bytes. Ya habían recibido informes sobre la corrupción de dichos objetos anteriormente, pero cada vez las investigaciones se estrellaban contra la pared.

Era muy difícil investigar la corrupción de memoria en virtud de su naturaleza. A menudo, las corrupciones de memoria simplemente eluden la detección, por ejemplo, si se corrompe la memoria no utilizada. A veces se puede tener suerte cuando la corrupción no daña algo crítico. Pero incluso si lleva a un fallo del kernel es difícil entender que la razón del fallo fue la corrupción de memoria.

Es aún más difícil comprender la naturaleza de la corrupción. Normalmente, esto se debe a use-after-free y, por tanto, hay que comprobar la asignación, inicialización, recuento de referencias y liberación de objetos corruptos. Sin embargo, en el caso de la losa kmalloc-192, las cosas son peores: se utiliza para guardar muchos objetos diferentes. El equipo de Virtuozzo ha intentado rastrear los más populares y ha fallado.

Sin embargo, de vez en cuando el equipo de Virtuozzo encontraba algo. En febrero, Vasily descubrió un error que causaba corrupción de memoria en kmalloc-192.

Esperaba haber resuelto el problema. Pero un día FastVPS llegó con el mismo problema. El equipo de Vasily les pidió que reprodujeran el problema en el kernel con la solución anterior, pero esto no ayudó, el problema se repitió.

Normalmente, en estos casos, Virtuozzo usa la depuración del kernel con la depuración multipropósito adicional. Los clientes no usan kernels de depuración en producción ya que disminuye drásticamente el rendimiento y es totalmente inaceptable para nuestros hosts. Sin embargo, FastVPS trasladó el kernel de depuración a producción. Sufrieron algún tiempo, pero como el problema no se reprodujo, volvieron al kernel normal.

Para detectar el problema en el kernel normal, Virtuozzo pidió a FastVPN que habilitara slub_debug. 

También disminuye el rendimiento y aumenta el consumo de memoria, hace comprobaciones adicionales de memoria al asignar y liberar objetos, y permite rastrear cómo se utilizó un objeto corrupto en el pasado. Pero aún así, el problema no se reprodujo y los nodos con slub_debug habilitado funcionaban bien. Pero al final, a principios de Junio, el equipo de Virtuozzo recibió un informe del nodo con slub_debug habilitado. A partir de este informe, entendieron qué objeto causaba la corrupción de memoria y también entendieron la naturaleza de la corrupción - no era use-after-free sino access-beyond-end-of-object considerablemente más raro.

Esto ayudó esencialmente en la investigación y un par de días después Vasily descubrió la causa del problema.

 

Para saber cuándo estará disponible el parche de inmediato, siga esta entrada del blog o nuestro Twitter y Facebook Twitter y Facebook.

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín
Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín
Cerrar enlace