Otros tres fallos del kernel zombi demuestran por qué hay que parchear sistemáticamente

Muy recientemente, una vulnerabilidad muy conocida llamada Spectre resurgió debido a un exploit que se puso a disposición del público, y la falta de parches hizo que esta conocida vulnerabilidad volviera a suponer un peligro.

Y, una vez más, ocurrió algo parecido. Esta vez, los investigadores de seguridad han encontrado tres fallos críticos en un código del kernel de Linux de hace 15 años. Un código tan antiguo ya debería haber sido analizado a fondo en busca de fallos, y nadie sabe con qué frecuencia han explotado estas vulnerabilidades los delincuentes.

Se han publicado parches paraCentOS 8, Oracle EL8, RHEL8, CloudLinux 7h, CloudLinux 8, AlmaLinux OS, Ubuntu Bionic HWE, Debian 10, Debian 10 Cloud, Debian 9 Backports y Proxmox VE6.

Además, ya están disponibles los parches para CloudLinux 6h, CloudLinux 7, CentOS 7, CentOS 7-plus, Oracle EL7 y RHEL 7.

En este artículo, describimos las tres vulnerabilidades que acaban de descubrirse, explicamos por qué el código fuente abierto no siempre se examina tan bien como debería (o por las personas adecuadas) y señalamos la importancia de aplicar parches de forma coherente.

Contenido

1. El antiguo código vuelve a perseguirnos

2. Defectos evidentes de codificación

3. Eres vulnerable aunque no utilices SCSI

4. Sólo porque el código sea de código abierto y se pueda consultar libremente ....

5. Los parches pueden salvar sus servidores

6. Considere la aplicación automatizada de parches

7. Calendario de publicación de parches

El antiguo código vuelve a perseguirnos

Lo sorprendente de muchos sistemas operativos modernos es que el código subyacente puede ser bastante antiguo. A medida que Linux evolucionaba desde sus orígenes en 1991, el núcleo se actualizaba continuamente, pero eso no significa que se reescribiera por completo. Se añadió, actualizó y eliminó código, pero no de una sola vez.

Como resultado, la versión moderna y actual del sistema operativo Linux que está utilizando puede contener código de hace décadas. Y es en código de más de una década de antigüedad donde se encontraron tres vulnerabilidades - registradas como CVE-2021-27363, CVE-2021-27364 y CVE-2021-27365.

No vamos a discutir las tres vulnerabilidades en gran profundidad en este artículo - puedes leer la cobertura original en GRIMM. Pero he aquí un breve resumen.

Los investigadores de GRIMM estaban, como ellos dicen, examinando casualmente el código del núcleo de Linux cuando les saltó a la vista una vulnerabilidad de seguridad extremadamente visible. En la serie de tres fallos notificados por la empresa, el primero era totalmente obvio. También reflejaba una falta de concienciación sobre los riesgos de seguridad en el momento en que se escribió el código.

Este código estaba presente en todas las versiones del kernel hasta la 5.11.3. Esto se traduce en fallos que afectan a todas las distribuciones de Linux y a todas las versiones que se remontan 15 años atrás.

Defectos evidentes de codificación

El equipo de GRIMM descubrió un problema en el código del controlador SCSI. Era obvio: el programador no especificó un parámetro de longitud al incluir char *buf en un área del código. Sin validación de longitud, un atacante podría, con un poco de esfuerzo, explotar este código para lanzar un ataque.

La segunda y tercera vulnerabilidades se localizaban en el subsistema iSCSI de Linux. En la segunda, el programador utilizó una dirección del kernel como manejador (lo que podría permitir a un atacante eludir la asignación aleatoria del espacio de direcciones del kernel). Aleatorización de la disposición del espacio de direcciones del kernel) y en la tercera, el programador no validó los datos de usuario en el kernel.

Las tres vulnerabilidades apuntan a fallos de programación comunes que conducen a problemas de seguridad - pero en el momento en que se escribió el código, los programadores no eran tan conscientes de estos problemas. Hoy en día, estos fallos de programación permiten a un actor malintencionado ejecutar un ataque de escalada de privilegios local en múltiples distribuciones de Linux.

Eres vulnerable aunque no utilices SCSI

Las tres últimas vulnerabilidades están relacionadas con los controladores SCSI. SCSI, abreviatura de small computer systems interface (interfaz de pequeños sistemas informáticos), es un estándar de 1986 para conectar ordenadores y periféricos. Ha evolucionado a lo largo de los años y sigue utilizándose a través de estándares como Serial Attached SCSI (SAS) e iSCSI, que es esencialmente SCSI sobre TCP.

Pero incluso si su carga de trabajo no depende de SCSI, estas vulnerabilidades pueden afectar a sus servidores. La razón de esto es la forma en que los paquetes del kernel de Linux dependen unos de otros. El código del controlador SCSI puede cargarse en la memoria de su servidor incluso si no tiene un dispositivo SCSI conectado a su servidor, simplemente debido a las dependencias.

Como ejemplo sencillo, tomemos iSCSI, que sigue siendo una forma fiable de acceder a datos centralizados a través de una red. Si tu servidor llama a iSCSI, a su vez llamará al código SCSI en el que se encontraron las vulnerabilidades. Esto ocurre automáticamente cuando el núcleo de Linux identifica que la funcionalidad de un módulo puede ser necesaria y carga el módulo.

A su vez, los actores de amenazas pueden confiar en el hecho de que los módulos se cargan automáticamente bajo demanda para explotar vulnerabilidades en código que es muy posible que nunca utilices en tu carga de trabajo.

Sólo porque el código sea de código abierto y se pueda consultar libremente ....

Hay un aspecto interesante en las tres vulnerabilidades que acabamos de enumerar. El código fuente abierto está, por definición, abierto al escrutinio. El código se publica en el dominio público y se puede ver y experimentar con él libremente.

Al menos en teoría, esto podría significar que el código fuente abierto es muy seguro porque está muy abierto al escrutinio. Esta es la suposición que mucha gente hace sobre el código abierto.

Sin embargo, las tres vulnerabilidades de las que hablamos se encontraron en código que ha formado parte del núcleo de Linux durante 15 años. Cabría pensar que estas vulnerabilidades tan visibles se habrían encontrado hace mucho tiempo, pero no fue así.

Así que, en cierto modo, la premisa de que el código fuente abierto es más seguro porque está abierto al escrutinio es posiblemente menos válida de lo que parece a primera vista.

Por otro lado, también es difícil saber si algún actores de amenazas persistentes avanzadas (APT) encontraron estas vulnerabilidades antes que los investigadores de seguridad de sombrero blanco, y qué hicieron con el conocimiento. El enorme volumen de vulnerabilidades del kernel de Linux descubiertas cada año también apunta a muchas vulnerabilidades desconocidas aún por descubrir que podrían dar lugar a brechas de seguridad.

Los parches pueden salvar sus servidores

Las vulnerabilidades del kernel de Linux siguen acumulándose y, al parecer, el código de hace 15 años todavía puede dar sorpresas. Aunque no se pueden aplicar parches contra las vulnerabilidades que aún no han sido descubiertas por los investigadores de seguridad, sí se pueden aplicar parches contra las vulnerabilidades y los exploits asociados que son de dominio público. No hacerlo sería una tontería.

Los parches contra vulnerabilidades conocidas también refuerzan su sistema. Incluso si un actor logra entrar en su red debido a una vulnerabilidad que aún no ha sido descubierta por los investigadores, el movimiento lateral será más difícil si sus sistemas están constantemente parcheados contra exploits conocidos.

Pero, como todos sabemos, la aplicación sistemática de parches no es fácil. A menudo es necesario reiniciar, desconectar los servidores e interrumpir los servicios. También hay que tener en cuenta las horas de trabajo que conlleva: parchear lleva su tiempo. Por eso, a menudo se descuida la aplicación de parches.

Considere la aplicación automatizada de parches

Las empresas que dependen de sistemas operativos basados en Linux tienen la opción de desplegar parches automatizados que eliminan la necesidad de aplicar manualmente los parches del sistema operativo.

En el caso de la solución de parcheo automatizado KernelCareviene con la ventaja adicional de la aplicación de parches en directo y sin reiniciar. En otras palabras, KernelCare puede parchear automáticamente sus servidores y hacerlo en directo, sin necesidad de reiniciar el servidor.

Sin embargo, sea cual sea la vía que elija -parcheo manual cuidadoso o una herramienta de parcheo en vivo como KernelCare-, es fundamental que aplique parches de forma coherente para proteger su carga de trabajo frente a las amenazas existentes y emergentes.

Calendario de publicación de parches

El equipo de KernelCare está trabajando ahora mismo en parches sin reinicio para estas vulnerabilidades. La distribución de los primeros parches está prevista para el 18 de marzo. Mantente atento a esta entrada del blog para recibir una actualización cuando salgan los parches.