La Gran Inundación de Kernel CVE de 2024

Ir directamente al resumen generado por IA de esta entrada del blog

"Sólo hacemos lo que cve.org quiere que hagamos" fue repetido varias veces por Greg K-H en una presentación reciente. A principios de este año, el nuevo estatus CNA (CVE Numbering Authority) del equipo del Kernel sorprendió a muchos en el ámbito de la seguridad. No sólo la postura anterior era completamente contraria al sistema CVE - "¡Quemadlos!" fue una solución propuesta-, sino que estaban utilizando un enfoque diferente para rastrear las vulnerabilidades (commit ids) y no hacerlas públicas como fallos de seguridad en primer lugar.

El cambio de CNA ha tenido un efecto dominó en todo el sector, por razones cada vez más evidentes: no sólo hay más CVE, sino que su enorme número dificulta mucho el seguimiento, el análisis y la identificación de los más importantes.

Pero todo esto ha sido discutido previamente por nosotros (y por muchos otros en la industria). Incluso existe un informe que publicamos hace unos mesessi le apetece.

Lo interesante es el punto de vista del propio equipo de Kernel sobre esta cuestión y, en este artículo, vamos a diseccionar la última presentación e identificar el problema que se eludió durante la misma.

Todo el texto citado a continuación está extraído de la presentación "Las CVE están vivas, ¡pero que no cunda el pánico!" de Greg K-H, manteniendo la mayor parte posible del contexto.

El elefante en la habitación

Empecemos con algunas cifras. Se facilitan explícitamente en la presentación. El Kernel CNA está emitiendo actualmente (en octubre de 2024) una media de 55 nuevos CVEs por semana. Esto es ligeramente inferior a los 60 por semana que se produjeron durante los primeros meses de actividad de la CNA. Sin embargo, en años anteriores se producían, según la presentación, unos 20 CVEs por trimestre.

La política inicial propuesta por la CNA del núcleo se interpretó como un enfoque de "todos los fallos obtienen una clave". Ahora se ha ampliado en el sentido de que sólo alrededor del 20% de los fallos obtienen realmente una - y eso nos da 55 por semana. "Eso es mucho". Siguiendo la lista de correo del Núcleo Linux, eso parece correcto.

El proceso es el siguiente: por cada commit estable, hay (al menos) tres personas que lo examinan y deciden si merece un CVE o no. Esto se discute públicamente cuando no hay consenso. Si se alcanza dicho consenso, se asigna un CVE.

Cuando se asigna un CVE a un fallo concreto, aún puede revocarse a posteriori si se presentan argumentos convincentes. Esto supone entre el 1% y el 2% de los CVE asignados.

El núcleo CNA "no es el nº 1"

...excepto que lo es. Debido a las (muy grandes) cifras implicadas, y obviamente para responder a las críticas, la presentación incluye una lista de otros proyectos y el número de CVEs semanales que generan. WordPress, con 112 por semana, está a la cabeza, con la salvedad de que no es realmente wordpress, ya que incluye todos los plugins y temas, por lo que en realidad no son 112 por semana. MITRE aparece con 95 por semana, pero tampoco se trata de un único proyecto. Windows (11-12), Chrome (6), macOS (6), iOS (2-3) también están en la lista. El hecho de que el kernel acumule más CVE que cualquier otro proyecto individual, y más que todos los sistemas operativos de la competencia juntos, podría indicar más sobre posibles problemas con el proceso que con el propio kernel.

¿Por qué ha ocurrido esto?

La razón declarada para empezar a publicar CVEs fue doble: en primer lugar, cve.org permitía ahora que los proyectos de código abierto tuvieran su propio CNA y, en segundo lugar, existen leyes y normativas que exigen la divulgación de vulnerabilidades en diferentes jurisdicciones (con más por venir).

"Estamos obligados a hacerlo" [en referencia a la emisión de CVE], así que no es como si el proverbial genio pudiera volver a meterse en la botella.

¿Qué constituye una vulnerabilidad?

Una de las principales diferencias entre la CNA del Kernel y las CNA de otros proyectos es, como ya se ha mencionado, el gran número de CVE emitidas. Esto se reduce a la interpretación de la definición de CVE por cve.org. Según la lectura del equipo del Kernel, los siguientes fallos obligan a la creación de un nuevo CVE (citado de la presentación):

"Cualquier fallo o reinicio provocado por el usuario
Uso de la memoria después de liberarla / fuga / desbordamiento
Comprobación incorrecta de los límites
Denegación de servicio
Errores lógicos
Muchas otras cosas".

Las siguientes NO se consideran específicamente vulnerabilidades y no obtendrán CVEs:

" Corrupción / pérdida de datos
Problemas de rendimiento
Corrección de errores no provocados externamente
No hay CVE de hardware".

Concretamente, el primer punto de la segunda lista, la corrupción de datos, merece una explicación más larga durante la presentación y, francamente, no considerar los posibles fallos de pérdida de datos como problemas de seguridad ignora los posibles ataques de denegación de servicio asociados a esto (como señaló correctamente un miembro del público durante las preguntas y respuestas). ¿El motivo? "Seguimos las directrices de cve.org. Es su problema, no el nuestro". No es una postura muy útil.

"Buena suerte resolviendo esto".

El gran problema de las distribuciones para empresas

A la presentación asistieron representantes de distintos proveedores de distribución, y durante las preguntas y respuestas dejaron muy clara su opinión al respecto: no estaban contentos, por decirlo suavemente.

El razonamiento aquí es que, si estás consumiendo el kernel e integrándolo en tu entorno, entonces (deberías) tener una buena comprensión de lo que estás usando, y por lo tanto sería menos insoportable identificar los CVEs que son realmente significativos para tu entorno particular - no necesitas preocuparte por el código que nunca se usa o se carga - por lo que una parte considerable de los 55 CVEs por semana no importa realmente en cada caso particular.

Sin embargo, los vendedores de distribuciones se encuentran en una posición más cercana al equipo del núcleo que a los usuarios finales. Una distribución puede utilizarse de infinitas maneras y en situaciones diferentes y, al igual que el equipo del kernel, el vendedor no puede pretender saber qué partes del kernel serán relevantes o no. Como resultado, tienen que abordar todas las vulnerabilidades que se les presentan. Esto repercute en las empresas que trabajan sobre las versiones del proveedor de distribución.

De modo que cada una de esas 55 CVE semanales tiene que ser analizada, puntuada, corregida, probada y puesta a disposición de los clientes empresariales. Si estabas buscando una razón por la que los boletines de seguridad de los proveedores incluyen ahora cientos de CVE, es porque se agrupan cada pocas semanas.

Sin embargo, sería cuestión de transponer las correcciones de aguas arriba a aguas abajo y ya está, ¿no? Bueno, hay más que eso.

Los CVEs asignados por la CNA del Kernel sólo hacen referencia al commit de la corrección. Si hay toda una cadena de otros parches que son necesarios para que la corrección se aplique, o funcione correctamente, eso se deja como un ejercicio para el lector.

Además, "no se prueban independientemente, sólo en bloque". Esto se vuelve inútil en cuanto una distribución aplica alguna personalización, ya que entonces hay que repetir todas las pruebas.

"Las Enterprise Distros tienen un problema, autoinfligido, y no tengo ninguna simpatía" [hablando de las correcciones de versiones anteriores del kernel que se distribuyen y son compatibles con los proveedores de distribución]. Efectivamente.

"No es mi problema".

El usuario final/la organización

"[Es necesario actualizar al núcleo más reciente] y reiniciar, o clasificar todas las correcciones, aplicar las pertinentes y reiniciar. Se puede utilizar live patching". Al mismo tiempo, reconoce que muchos no pueden, ya que su infraestructura no puede soportar el número de reinicios. Así que hay que triar 55 CVEs por semana, cada semana, o tomar la última versión. Se trata de una elección pírrica en el mundo real que resulta extremadamente costosa en un entorno empresarial.

La tercera alternativa, y la única que se puede aplicar, es parchear sus sistemas.

El estado de las cosas

"Estamos haciendo exactamente lo que cve.org nos pidió que hiciéramos" parece ser la postura por defecto a la hora de defender el proceso actual. Aceptar eso al pie de la letra, y que "no estamos causando una denegación de servicio" [en el proceso CVE] tampoco es la intención. Pero la situación real a la que se enfrentan muchas empresas, proveedores de distribución y empresas de ciberseguridad, y los problemas de cumplimiento y seguridad que conlleva tener sistemas marcados por 55 nuevas vulnerabilidades cada semana, no ayuda realmente a aceptar el estado actual de las cosas como otra cosa que un cumplimiento malintencionado (intencionado o accidental).

El tremendo trabajo realizado por el equipo de Kernel, y en particular por el pequeño equipo de Kernel CNA, merecía algo mejor, pero desgraciadamente está causando demasiada pena y sufrimiento a miles de profesionales de la seguridad cuyo ecosistema entero está ahora inundado de nuevos problemas, a menudo sin resolver, que no hacen más que añadir más carga a un entorno ya de por sí estresante.

"Está causando cierta agitación y algunos baches en el ecosistema. Sé que me van a citar por esto". No bromeo.

Nota: Gracias a Greg K-H por la transparencia del proceso y por mirar detrás del telón.

Resumen