{"id":2933,"date":"2024-10-08T20:47:42","date_gmt":"2024-10-09T01:47:42","guid":{"rendered":"https:\/\/zidrave.net\/?p=2933"},"modified":"2024-10-08T20:47:42","modified_gmt":"2024-10-09T01:47:42","slug":"linux-criticas-razones-y-consecuencias-del-exceso-de-cve-en-el-kernel","status":"publish","type":"post","link":"https:\/\/zidrave.net\/index.php\/2024\/10\/08\/linux-criticas-razones-y-consecuencias-del-exceso-de-cve-en-el-kernel\/","title":{"rendered":"Linux: Cr\u00edticas, razones y consecuencias del exceso de CVE en el kernel"},"content":{"rendered":"\n

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\u00f3n 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\u00f3n del kernel, otros ven este aumento como un reflejo positivo de una mayor atenci\u00f3n a la seguridad y correcciones que anteriormente se pasaban por alto.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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\u00f3n a los parches de seguridad, especialmente aquellos que no estaban etiquetados expl\u00edcitamente como tales. Las empresas m\u00e1s grandes del sector Linux est\u00e1n trabajando en nuevas herramientas y colaboraciones que faciliten la gesti\u00f3n de estas vulnerabilidades, aunque ser\u00e1 necesario tiempo para implementar estas soluciones.<\/p>\n\n\n\n

La carga adicional que esto supone para los administradores, especialmente los aficionados, tambi\u00e9n est\u00e1 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\u00f3n hacia una mayor seguridad requiere un esfuerzo considerable y prolongado, lo que implica que los cambios no ser\u00e1n inmediatos.<\/p>\n\n\n\n

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\u00edos de seguridad que surgen en un entorno cada vez m\u00e1s complejo y din\u00e1mico. <\/p>\n\n\n\n

M\u00e1s de 3.000 CVE desde febrero<\/h2>\n\n\n\n

La raz\u00f3n del cambio de situaci\u00f3n son los desarrolladores del kernel llamado Linux. Durante d\u00e9cadas no les hab\u00edan importado en lo m\u00e1s m\u00ednimo 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\u00edan cada vez m\u00e1s CVE para vulnerabilidades cuestionables del kernel, los desarrolladores se vieron obligados a convertirse en una CNA (Autoridad de Numeraci\u00f3n CVE) a principios de a\u00f1o para poder controlar la emisi\u00f3n de CVE para Linux ellos mismos, de forma similar a otras fuentes abiertas. Proyectos anteriores.<\/p>\n\n\n\n

Los desarrolladores responsables de Linux han emitido desde febrero alrededor de 3.375 etiquetas CVE, incluidas todo tipo de vulnerabilidades que se hab\u00edan solucionado en a\u00f1os anteriores debido a las especificaciones de la fundaci\u00f3n de la empresa. Tras objeciones, los responsables retiraron alrededor de un centenar de estos CVE. Muchos forasteros, pero tambi\u00e9n todo tipo de desarrolladores del kernel oficial, critican que muchos de los otros CVE tampoco est\u00e1n justificados porque no se ha parcheado ninguna vulnerabilidad real.<\/p>\n\n\n\n

Los CVE para vulnerabilidades, por peque\u00f1as que sean, son obligatorios<\/h2>\n\n\n\n

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\u00f3n de CVE le obligar\u00edan a \u00e9l y a los dem\u00e1s responsables a asignar un Etiqueta CVE a cualquier vulnerabilidad potencial que las elimine. Tambi\u00e9n afirma que la gente utiliza Linux de diversas maneras, lo que hace muy dif\u00edcil estimar si una correcci\u00f3n aparentemente inofensiva es realmente relevante para la seguridad en determinadas \u00e1reas de uso.<\/p>\n\n\n\n

Para aquellos interesados \u200b\u200ben los detalles, recomendamos la presentaci\u00f3n y el v\u00eddeo de una charla reciente de Kroah-Hartman , en la que explica estos aspectos con m\u00e1s 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\u00e1s de 110 por semana. Tambi\u00e9n entra en detalles sobre el procedimiento: la asignaci\u00f3n se produce s\u00f3lo unos d\u00edas o semanas despu\u00e9s de que las correcciones se hayan incorporado en las nuevas versiones del kernel destinadas a los usuarios.<\/p>\n\n\n\n

Tres personas deben ponerse de acuerdo para conceder un CVE<\/h2>\n\n\n\n

Los responsables s\u00f3lo otorgan CVE a las vulnerabilidades si tres desarrolladores actualmente involucrados votan por ellas en el proceso de revisi\u00f3n p\u00fablica . Los propios programadores de los cambios o los encargados del mantenimiento del respectivo c\u00f3digo del kernel no est\u00e1n involucrados, pero a menudo no son expertos en seguridad y los encargados del mantenimiento a menudo ya est\u00e1n en sus l\u00edmites o los han superado, como Kroah-Hartman enfatiz\u00f3 recientemente en otro lugar. Como ha sido el caso durante muchos a\u00f1os, todav\u00eda recomienda a los usuarios que simplemente utilicen la \u00faltima versi\u00f3n de la \u00faltima serie de kernel estable o de largo plazo para evitar lagunas conocidas.<\/p>\n\n\n\n

La elecci\u00f3n entre dos males<\/h2>\n\n\n\n

En una diapositiva de la conferencia, Kroah-Hartman tambi\u00e9n cita a Kees Cook, cuyo gran compromiso durante m\u00e1s de una d\u00e9cada ha hecho que el kernel de Linux sea significativamente m\u00e1s seguro. Seg\u00fan \u00e9l, los usuarios que se preocupan por el kernel m\u00e1s seguro s\u00f3lo pueden elegir entre dos opciones: utilizar la \u00faltima versi\u00f3n de una serie actual o simplemente examinar cada entrada CVE con m\u00e1s detalle, para luego aplicar las correcciones a esas las vulnerabilidades que son relevantes para el kernel utilizado son relevantes en el \u00e1rea de aplicaci\u00f3n espec\u00edfica. Ambos causan mucho trabajo e inconvenientes, por ejemplo cuando los reinicios son dif\u00edciles o imposibles; Seg\u00fan Cook, cada uno debe comprobar por s\u00ed mismo cu\u00e1l de los dos enfoques es m\u00e1s sencillo en su entorno respectivo.<\/p>\n\n\n\n

Los comentarios de Cook surgen de una discusi\u00f3n abierta sobre la situaci\u00f3n 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\u00f1as que utilizan Linux internamente o en productos. El grupo toc\u00f3 \u00e1reas muy diferentes y dej\u00f3 todo tipo de preguntas sin respuesta. Sin embargo, una cosa u otra es previsible.<\/p>\n\n\n\n

Los modelos de amenazas est\u00e1n destinados a permitir la colaboraci\u00f3n.<\/p>\n\n\n\n

Los desarrolladores de varias empresas parecieron bastante espec\u00edficos acerca de la definici\u00f3n de un pu\u00f1ado de modelos de amenazas. Las partes interesadas pueden entonces revisar los CVE en una divisi\u00f3n del trabajo seg\u00fan principios de c\u00f3digo abierto y determinar para cada uno si es relevante para el modelo de amenaza respectivo.<\/p>\n\n\n\n

Uno de esos modelos de amenazas podr\u00eda ser el del \u00abproveedor de la nube\u00bb: hardware de servidor moderno ARM64 y x86-64 con usuarios totalmente confiables, pero m\u00e1quinas virtuales con software no confiable. Empresas como Amazon\/AWS, Google, IBM y Microsoft podr\u00edan entonces trabajar juntas para determinar qu\u00e9 CVE son relevantes para este modelo de amenaza en lugar de tener que hacerlo internamente. Los resultados de estos y otros an\u00e1lisis similares podr\u00edan luego regresar a los archivos JSON, que ya agrupan de forma centralizada todos los detalles sobre los CVE.<\/p>\n\n\n\n

Mucho esfuerzo para un Linux empresarial flexible<\/h2>\n\n\n\n

Otros modelos de amenazas abordados fueron Automotive o Enterprise Linux. Esto \u00faltimo, si alguna vez sucede, probablemente sea m\u00e1s adecuado para distribuciones de Linux que est\u00e1n claramente definidas en t\u00e9rminos de soporte de hardware y \u00e1reas de aplicaci\u00f3n. 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\u00eda un esfuerzo enorme. Si se quisiera incluir kernels compilados con muchas m\u00e1s funciones y controladores, como los de Debian, el esfuerzo volver\u00eda a aumentar significativamente, posiblemente hasta el punto de que nadie podr\u00eda hacer el trabajo necesario voluntariamente o pagar a alguien para que lo haga.<\/p>\n\n\n\n

Un aspecto relacionado s\u00f3lo se abord\u00f3 en el grupo de discusi\u00f3n, pero se discuti\u00f3 en el entorno: la falta de herramientas de c\u00f3digo abierto que verifiquen si el c\u00f3digo afectado por el CVE est\u00e1 incluido en el n\u00facleo utilizado, ya sea directamente o en un m\u00f3dulo que es local podr\u00eda eliminarse o bloquearse f\u00e1cilmente. 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\u00f3n de tiempo antes de que alguien lance una herramienta de este tipo bajo una licencia de c\u00f3digo abierto para poder trabajar juntos en el futuro dada la situaci\u00f3n.<\/p>\n\n\n\n

S\u00f3lo se toc\u00f3 el tema de los parches en vivo porque todav\u00eda quedan preguntas sin respuesta. Aplicar todas o al menos una gran parte de las correcciones de CVE en tiempo de ejecuci\u00f3n usando esta t\u00e9cnica quiz\u00e1s ser\u00eda te\u00f3ricamente concebible, pero ser\u00eda dif\u00edcil de implementar en la pr\u00e1ctica: crear y verificar parches en vivo tan complejos requiere demasiado trabajo y tiempo. En \u00faltima instancia, esto probablemente permitir\u00e1 evitar reinicios durante algunas semanas, pero no durante muchos meses.<\/p>\n\n\n\n

Sin embargo, un participante en el grupo de discusi\u00f3n mencion\u00f3 que los numerosos CVE son un gran problema en \u00e1reas donde las actualizaciones son dif\u00edciles y costosas debido a las regulaciones de certificaci\u00f3n, por ejemplo cuando se usa Linux en hospitales. Kroah-Hartman explic\u00f3 que los legisladores estadounidenses y de la UE han reconocido el problema y est\u00e1n trabajando en soluciones, pero esto lleva tiempo.<\/p>\n","protected":false},"excerpt":{"rendered":"

El kernel de Linux ha experimentado un aumento significativo en<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[2375,3193],"tags":[16,7386,3057,251,7388,7387,2266,7389,3197,474,653,1317,2537,272,2871,4591,1408,1524,189,17,195],"class_list":["post-2933","post","type-post","status-publish","format-standard","hentry","category-internet","category-linux","tag-administradores","tag-aficionados","tag-carga","tag-colaboracion","tag-correcciones","tag-cve","tag-desarrolladores","tag-dinamico","tag-distribucion","tag-eficiencia","tag-empresas","tag-gestion","tag-herramientas","tag-industria","tag-infraestructura","tag-kernel","tag-linux","tag-parches","tag-proteccion","tag-seguridad","tag-vulnerabilidades"],"_links":{"self":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts\/2933","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/comments?post=2933"}],"version-history":[{"count":1,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts\/2933\/revisions"}],"predecessor-version":[{"id":2934,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/posts\/2933\/revisions\/2934"}],"wp:attachment":[{"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/media?parent=2933"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/categories?post=2933"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zidrave.net\/index.php\/wp-json\/wp\/v2\/tags?post=2933"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}