El kernel de Linux ha experimentado un aumento significativo en la cantidad de vulnerabilidades de seguridad publicadas semanalmente, con aproximadamente 55 CVE (Common Vulnerabilities and Exposures) divulgadas, en comparación con las cuatro o seis semanales que eran comunes hasta hace poco. Este incremento ha generado diversas reacciones entre administradores y desarrolladores de la comunidad Linux. Mientras algunos lo consideran una carga adicional que dificulta la gestión del kernel, otros ven este aumento como un reflejo positivo de una mayor atención a la seguridad y correcciones que anteriormente se pasaban por alto.
Los desarrolladores del kernel han argumentado que este incremento en CVEs no es un problema, sino una oportunidad para mejorar la seguridad en general. Para ellos, las quejas de algunos distribuidores sugieren que hasta ahora no estaban prestando suficiente atención a los parches de seguridad, especialmente aquellos que no estaban etiquetados explícitamente como tales. Las empresas más grandes del sector Linux están trabajando en nuevas herramientas y colaboraciones que faciliten la gestión de estas vulnerabilidades, aunque será necesario tiempo para implementar estas soluciones.
La carga adicional que esto supone para los administradores, especialmente los aficionados, también está siendo reconocida, y se espera que a largo plazo las mejoras en la infraestructura de seguridad del kernel beneficien a todos los usuarios. Sin embargo, esta transición hacia una mayor seguridad requiere un esfuerzo considerable y prolongado, lo que implica que los cambios no serán inmediatos.
Este tema subraya la importancia de un enfoque colaborativo y la necesidad de nuevas herramientas que permitan a la comunidad Linux enfrentar de manera eficiente los desafíos de seguridad que surgen en un entorno cada vez más complejo y dinámico.
Más de 3.000 CVE desde febrero
La razón del cambio de situación son los desarrolladores del kernel llamado Linux. Durante décadas no les habían importado en lo más mínimo etiquetas como CVE (vulnerabilidades y exposiciones comunes); Una y otra vez incluso han ocultado los ID de CVE o incluso los han eliminado de las descripciones de los parches para ocultar el aspecto de seguridad de los cambios. Pero debido a que a terceros se les concedían cada vez más CVE para vulnerabilidades cuestionables del kernel, los desarrolladores se vieron obligados a convertirse en una CNA (Autoridad de Numeración CVE) a principios de año para poder controlar la emisión de CVE para Linux ellos mismos, de forma similar a otras fuentes abiertas. Proyectos anteriores.
Los desarrolladores responsables de Linux han emitido desde febrero alrededor de 3.375 etiquetas CVE, incluidas todo tipo de vulnerabilidades que se habían solucionado en años anteriores debido a las especificaciones de la fundación de la empresa. Tras objeciones, los responsables retiraron alrededor de un centenar de estos CVE. Muchos forasteros, pero también todo tipo de desarrolladores del kernel oficial, critican que muchos de los otros CVE tampoco están justificados porque no se ha parcheado ninguna vulnerabilidad real.
Los CVE para vulnerabilidades, por pequeñas que sean, son obligatorios
Greg Kroah-Hartman, como principal impulsor de todo esto y segundo desarrollador del kernel, siempre reacciona de la misma manera ante estas acusaciones: Las directrices para la asignación de CVE le obligarían a él y a los demás responsables a asignar un Etiqueta CVE a cualquier vulnerabilidad potencial que las elimine. También afirma que la gente utiliza Linux de diversas maneras, lo que hace muy difícil estimar si una corrección aparentemente inofensiva es realmente relevante para la seguridad en determinadas áreas de uso.
Para aquellos interesados en los detalles, recomendamos la presentación y el vídeo de una charla reciente de Kroah-Hartman , en la que explica estos aspectos con más detalle y proporciona muchas otras ideas. Afirma que el kernel no es el favorito con alrededor de 55 CVE por semana: WordPress, por ejemplo, publica más de 110 por semana. También entra en detalles sobre el procedimiento: la asignación se produce sólo unos días o semanas después de que las correcciones se hayan incorporado en las nuevas versiones del kernel destinadas a los usuarios.
Tres personas deben ponerse de acuerdo para conceder un CVE
Los responsables sólo otorgan CVE a las vulnerabilidades si tres desarrolladores actualmente involucrados votan por ellas en el proceso de revisión pública . Los propios programadores de los cambios o los encargados del mantenimiento del respectivo código del kernel no están involucrados, pero a menudo no son expertos en seguridad y los encargados del mantenimiento a menudo ya están en sus límites o los han superado, como Kroah-Hartman enfatizó recientemente en otro lugar. Como ha sido el caso durante muchos años, todavía recomienda a los usuarios que simplemente utilicen la última versión de la última serie de kernel estable o de largo plazo para evitar lagunas conocidas.
La elección entre dos males
En una diapositiva de la conferencia, Kroah-Hartman también cita a Kees Cook, cuyo gran compromiso durante más de una década ha hecho que el kernel de Linux sea significativamente más seguro. Según él, los usuarios que se preocupan por el kernel más seguro sólo pueden elegir entre dos opciones: utilizar la última versión de una serie actual o simplemente examinar cada entrada CVE con más detalle, para luego aplicar las correcciones a esas las vulnerabilidades que son relevantes para el kernel utilizado son relevantes en el área de aplicación específica. Ambos causan mucho trabajo e inconvenientes, por ejemplo cuando los reinicios son difíciles o imposibles; Según Cook, cada uno debe comprobar por sí mismo cuál de los dos enfoques es más sencillo en su entorno respectivo.
Los comentarios de Cook surgen de una discusión abierta sobre la situación del nuevo kernel CVE que tuvo lugar recientemente en la Conferencia de Plomeros de Linux. Participaron desarrolladores de kernel de numerosas empresas grandes y pequeñas que utilizan Linux internamente o en productos. El grupo tocó áreas muy diferentes y dejó todo tipo de preguntas sin respuesta. Sin embargo, una cosa u otra es previsible.
Los modelos de amenazas están destinados a permitir la colaboración.
Los desarrolladores de varias empresas parecieron bastante específicos acerca de la definición de un puñado de modelos de amenazas. Las partes interesadas pueden entonces revisar los CVE en una división del trabajo según principios de código abierto y determinar para cada uno si es relevante para el modelo de amenaza respectivo.
Uno de esos modelos de amenazas podría ser el del «proveedor de la nube»: hardware de servidor moderno ARM64 y x86-64 con usuarios totalmente confiables, pero máquinas virtuales con software no confiable. Empresas como Amazon/AWS, Google, IBM y Microsoft podrían entonces trabajar juntas para determinar qué CVE son relevantes para este modelo de amenaza en lugar de tener que hacerlo internamente. Los resultados de estos y otros análisis similares podrían luego regresar a los archivos JSON, que ya agrupan de forma centralizada todos los detalles sobre los CVE.
Mucho esfuerzo para un Linux empresarial flexible
Otros modelos de amenazas abordados fueron Automotive o Enterprise Linux. Esto último, si alguna vez sucede, probablemente sea más adecuado para distribuciones de Linux que están claramente definidas en términos de soporte de hardware y áreas de aplicación. Es decir, aquellos que Amazon/AWS, Google, Meta, Microsoft, Oracle, Red Hat o SuSE ofrecen o utilizan internamente. Incluso para ellos, clasificar los CVE supondría un esfuerzo enorme. Si se quisiera incluir kernels compilados con muchas más funciones y controladores, como los de Debian, el esfuerzo volvería a aumentar significativamente, posiblemente hasta el punto de que nadie podría hacer el trabajo necesario voluntariamente o pagar a alguien para que lo haga.
Un aspecto relacionado sólo se abordó en el grupo de discusión, pero se discutió en el entorno: la falta de herramientas de código abierto que verifiquen si el código afectado por el CVE está incluido en el núcleo utilizado, ya sea directamente o en un módulo que es local podría eliminarse o bloquearse fácilmente. Al menos Google, Oracle y SuSE utilizan este tipo de herramientas internamente desde hace tiempo, como se sabe en la zona. Probablemente sea solo cuestión de tiempo antes de que alguien lance una herramienta de este tipo bajo una licencia de código abierto para poder trabajar juntos en el futuro dada la situación.
Sólo se tocó el tema de los parches en vivo porque todavía quedan preguntas sin respuesta. Aplicar todas o al menos una gran parte de las correcciones de CVE en tiempo de ejecución usando esta técnica quizás sería teóricamente concebible, pero sería difícil de implementar en la práctica: crear y verificar parches en vivo tan complejos requiere demasiado trabajo y tiempo. En última instancia, esto probablemente permitirá evitar reinicios durante algunas semanas, pero no durante muchos meses.
Sin embargo, un participante en el grupo de discusión mencionó que los numerosos CVE son un gran problema en áreas donde las actualizaciones son difíciles y costosas debido a las regulaciones de certificación, por ejemplo cuando se usa Linux en hospitales. Kroah-Hartman explicó que los legisladores estadounidenses y de la UE han reconocido el problema y están trabajando en soluciones, pero esto lleva tiempo.
