El 17 de diciembre, 2021 En su blog, el equipo de Google Open Source Insights explicó toda la situación que observaron con respecto a la vulnerabilidad Apache Log4j.. Describieron la vulnerabilidad generalizada y el progreso actual en la reparación del ecosistema JVM de código abierto.. Además, el equipo compartió sus opiniones sobre cuánto tiempo llevará solucionar esta vulnerabilidad en todo el ecosistema y dónde centrarse a continuación..
El pasado 9 de diciembre el ecosistema de seguridad de la información conoció la existencia de una vulnerabilidad que presenta un alto grado de gravedad y un impacto generalizado.. Decenas de miles de paquetes de software (artefactos en el ecosistema Java) y los proyectos utilizan una herramienta de registro popular, log4j que resultó tener las vulnerabilidades discutidas. Como explican los especialistas, estas vulnerabilidades permiten la ejecución remota de código explotando la tímida función de búsqueda JNDI descubierta por la biblioteca de registro log4j.. En muchas versiones de la biblioteca, la característica explotada existía de forma predeterminada..
La vulnerabilidad de Apache Log4j tardará un tiempo en solucionarse
No hace mucho, las vulnerabilidades de log4j reveladas afectaron a más de 35,000 paquetes java, numeración hasta el final 8% del repositorio central de Maven. Dado que el repositorio es el repositorio de paquetes Java más importante, provocó un gran resultado para la industria del software.. Los especialistas señalan que 8% es un resultado enorme para el resultado del ecosistema, mientras que el número promedio para el resultado de los avisos de Maven Central va con 2% y la mediana menor que 0.1%. Aunque los números mencionados no incluyen todos los paquetes de Java, por ejemplo, binarios distribuidos directamente.
En el momento de la publicación de la publicación, casi cinco mil de los artefactos en cuestión han sido reparados.. Y más 30,000 artefactos, muchos dependen de otro artefacto, todavía espero ser parcheado. El equipo menciona que cuentan un artefacto como arreglado si el artefacto tenía al menos una versión afectada y ha lanzado una versión estable mayor y no afectada. (eso es según versiones semánticas). En el caso de log4j, un artefacto se considera arreglado si se ha actualizado a 2.16.0 o ya no depende de log4j.
Dos problemas importantes obstaculizan el proceso de reparación
Aunque las situaciones en general pueden definirse como claras, los especialistas señalan dos problemas de solución importantes. El primer objetivo que definen es el hecho de que muchos artefactos dependen indirectamente de log4j.. Los de dependencia directa representan alrededor 7,000 de los artefactos afectados. En tal caso, cualquiera de sus versiones depende de una versión afectada de log4j-core o log4j-api., descrito en los CVE. La dependencia indirecta o dependencia transitiva significa las dependencias de las propias dependencias..
Todo el personal de esta dependencia crea importantes obstáculos para solucionarlo si lo miramos con cadenas de dependencia.. Aquí todo queda bastante claro.: Cuanto más profundo sea el vulnerabilidad se cae, Cuantos más pasos se deben seguir para solucionarlo. Según los gráficos de dependencia de los consumidores del equipo, los resultados del histograma mostraron grandes números.. En más que 80% de la vulnerabilidad del paquete tiene más de un nivel de profundidad. En la mayoría de los cuales está cinco niveles hacia abajo y en algunos nueve niveles hacia abajo.. El proceso de reparación requerirá ir primero a las dependencias más profundas y luego a todo el árbol..
Los rangos abiertos brindan la oportunidad de seleccionar la versión lanzada más recientemente
Otra dificultad radica en las elecciones a nivel de ecosistema en el algoritmo de resolución de dependencias y las convenciones de especificación de requisitos.. La práctica difiere de aquellas como npm, donde rutinariamente especifican rangos abiertos para requisitos de dependencia.. Los rangos abiertos brindan la oportunidad de seleccionar la versión lanzada más recientemente que satisfaga los requisitos de dependencia.. Y posteriormente introduce nuevas correcciones.. Los usuarios reciben una versión parcheada en la siguiente compilación después de la disponibilidad del parche.. Genera las dependencias más rápidamente..
“En el ecosistema Java, Es una práctica común especificar requisitos de versión "suaves": versiones exactas que utiliza el algoritmo de resolución si no aparece ninguna otra versión del mismo paquete antes en el gráfico de dependencia.. La propagación de una solución a menudo requiere una acción explícita por parte de los mantenedores para actualizar los requisitos de dependencia a una versión parcheada.," Equipo de conocimientos de código abierto escribió sobre este segundo problema.
Con esto, el equipo aconseja a la comunidad de código abierto que habilite actualizaciones de dependencia automatizadas y agregue mitigaciones de seguridad.. También proporcionaron una lista de 500 Paquetes afectados con algunos de los mayores usos transitivos.. En opinión de los especialistas, priorizar estos paquetes facilitará los esfuerzos de reparación y, posteriormente, desbloqueará más partes de la comunidad.. El equipo agradeció a los mantenedores y consumidores de código abierto que actualizaron sus versiones de log4j..
A la pregunta de cuánto tiempo llevaría arreglar todo por completo, el equipo expresó una opinión vaga.. Dicen que es difícil saberlo.. Si se trata de avisos críticos divulgados públicamente que afectan a los paquetes de Maven, entonces el proceso podría tardar un poco.. Dicen que menos de la mitad (48%) de los artefactos afectados por una vulnerabilidad han sido reparados. Pero en el frente de log4j las cosas parecen prometedoras con aproximadamente 13% que han sido arreglados.
