El 17 de diciembre, 2021 en su blog, Google Open Source Insights Team explicó toda la situación que observaron con respecto a la vulnerabilidad de 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 pensamientos sobre cuánto tiempo posiblemente tomará para que esta vulnerabilidad se solucione en todo el ecosistema y dónde enfocarse a continuación..
El 9 de diciembre, el ecosistema de seguridad de la información se enteró de la existencia de la vulnerabilidad que presenta un alto grado de gravedad e impacto generalizado.. Decenas de miles de paquetes de software (artefactos en el ecosistema de 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 al explotar la característica de búsqueda de JNDI tímida que pone al descubierto 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 tiempo, las vulnerabilidades de log4j reveladas afectaron a más de 35,000 Paquetes de Java, numeración a más 8% del repositorio de Maven Central. Dado que el repositorio es el repositorio de paquetes de Java más importante, provocó un resultado extenso 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 las advertencias 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, se han corregido casi cinco mil de los artefactos en cuestión.. Y más 30,000 artefactos, muchos dependen de otro artefacto, todavía espero ser parcheado. El equipo menciona que contaron un artefacto como arreglado si el artefacto tenía al menos una versión impactada y ha lanzado una versión estable mayor sin impacto. (eso está de acuerdo con el control de versiones semántico). En el caso de log4j, un artefacto se considera fijo si se ha actualizado a 2.16.0 o ya no depende de log4j.
Dos problemas importantes dificultan el proceso de reparación
Aunque las situaciones en general se pueden definir como claras, los especialistas señalan dos importantes problemas de reparación. El primer objetivo que definen es el hecho de que muchos artefactos dependen indirectamente de log4j. Los de dependencias directas 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 obstáculos importantes a la hora de arreglarlo si mirarlo con cadenas de dependencia. Aquí todo queda bastante claro: Cuanto más profundo es el vulnerabilidad se cae, Cuantos más pasos se deben seguir para solucionarlo. De acuerdo con 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 de los paquetes tiene más de un nivel de profundidad. En la mayoría de los cuales está cinco niveles hacia abajo y en unos nueve niveles hacia abajo.. El proceso de reparación requerirá ir primero a las dependencias más profundas primero 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 de forma rutinaria especifican rangos abiertos para los 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 incorpora 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 de Java, Es una práctica común especificar requisitos de versión "suave": 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 encargados del mantenimiento para actualizar los requisitos de dependencia a una versión parcheada.,” Equipo de Open Source Insights escribió sobre este segundo problema.
Con estos, el equipo asesora a la comunidad de código abierto para habilitar actualizaciones de dependencia automatizadas y agregar mitigaciones de seguridad.. También proporcionaron una lista de 500 paquetes afectados con algunos de los usos transitivos más altos. En opinión de los especialistas, priorizar estos paquetes facilitará los esfuerzos de reparación y, posteriormente, desbloqueará a más miembros de la comunidad.. El equipo agradeció a los consumidores y mantenedores de código abierto que actualizaron sus versiones de log4j.
Para la pregunta de cuánto tiempo tomaría arreglar por completo todo, el equipo expresó una opinión vaga.. Dicen que es dificil saber. Si todos los avisos críticos divulgados públicamente que afectan a los paquetes de Maven, entonces el proceso puede llevar un tiempo.. Dicen que menos de la mitad (48%) de los artefactos afectados por una vulnerabilidad se han solucionado. Pero en el frente de log4j, las cosas parecen ser prometedoras con aproximadamente 13% que han sido arreglados.
