Hace ahora dos años, tuvo lugar la difusión de una vulnerabilidad 'zero day' que afectó potencialmente a millones de usuarios de toda clase de plataformas online (de Steam a Cloudflare, de iCloud a Minecraft, etcétera): la denominada vulnerabilidad 'Log4Shell', así denominada porque afectaba a una casi desconocida biblioteca de código abierto denominada Apache Log4J.
Pero, aunque fuera poco conocida, lo cierto es que era (y sigue siendo) una pieza fundamental entre las aplicaciones (libres y privativas) del ecosistema Java, al tener la función de facilitar que éstas mantengan un registro de las actividades realizadas en tiempo de distribución.
Tan fundamental era esta pieza, que rápidamente se asignó a la vulnerabilidad una puntuación 10/10 en el CVSS (Common Scoring System). Por fortuna, tan sólo 24 horas después de difundirse la existencia de la vulnerabilidad, los mantenedores del proyecto Log4J habían sido capaces de lanzar la versión parcheada.
El escándalo de los voluntarios trabajando contrarreloj para Silicon Valley
Lo cual, como se reveló al poco tiempo, era un logro descomunal, pues el equipo de personas responsable de este software (usado, insistimos, por miles de grandes plataformas) era de tan sólo 10 personas... de las cuales sólo 3 pudieron contribuir en ese momento a crear el parche. ¿El motivo? Todos ellos eran desarrolladores voluntarios que trabajan en Log4J "en su tiempo libre". Alguno de ellos sólo pudo dormir dos horas aquella estresante noche.
Cuando esto se supo, muchos usuarios denunciaron la precaria situación de un proyecto tan crítico. Se criticó que la Fundación Apache tenga una amplia página detallando las responsabilidades de los programadores de sus proyectos, cuando es gente que trabaja por amor al arte... y, sobre todo, arreciaron las críticas contra las compañías multimillonarias que se benefician del software que esta gente desarrolla sin molestarse en realizar ninguna donación.
Tanto, que tan sólo un mes después de aquello, la propia Casa Blanca convocó una cumbre de las organizaciones open source, grandes tecnológicas y agencias federales estadounidenses para evitar nuevos casos de vulnerabilidades graves en proyectos open source críticos. Se llegó a hablar de establecer mecanismos para permitir la sostenibilidad de los mismos y acortar su tiempo de respuesta.
Pero, ¿cómo está la cosa doce meses después?
Así estaban Log4J y Log4Shell un año después...
Doce meses después de todo lo ocurrido el creador y principal responsable de Log4J, Ralph Goers, seguía teniendo dos trabajos "a tiempo completo", en el que Log4J es, precisamente, el no-remunerado. El número total de colaboradores (repetimos, todos ellos voluntarios) sólo se había incrementado en uno (1, sí).
Goers, al menos, ha visto como su número de patrocinadores en GitHub Sponsors se multiplicaba desde los tres (3, sí) que tenía cuando explotó el tema de Log4Shell hasta los 31 (otros 90 llegaron a patrocinarle en algún momento tras la polémica, pero ya se habían 'caído' para entonces).
Y mientras, entre el 30% y el 40% de las instalaciones de Log4J no se han molestado en instalar las versiones parcheadas del mismo. Nueve meses después del descubrimiento del problema, las agencias de ciberseguridad en los Estados Unidos, Reino Unido, Australia y Canadá lanzaron una advertencia: cibercriminales presuntamente financiados por el régimen de Irán seguían explotando las vulnerabilidades de Log4j para ejecutar campañas de ransomware.
¿Y ahora, dos años más tarde?
Una investigación llevada a cabo por la compañía de ciberseguridad Veracode reveló que es posible que la gran mayoría de las aplicaciones vulnerables nunca hayan llegado a actualizar la biblioteca Log4j después de que los desarrolladores la implementaron en sus proyectos, ya que el 32% ejecutaba versiones carentes de soporte de la misma, es decir, anteriores a 2015.
Por fortuna, la vulnerabilidad Log4Shell sólo afectaba a las versiones 2.0-beta9 a 2.15.0 de Log4j, por lo que el porcentaje de aplicaciones que siguen siendo vulnerables a la vulnerabilidad se reduce en teoría a sólo un 2,8%...
...si bien otro 3,8% sigue ejecutando la versión 2.17, una versión posterior al famoso parche, por lo que no está expuesta a ataques Log4Shell, pero sí es vulnerable a otra vulnerabilidad de ejecución remota de código.
Pero, en cuanto al respaldo humano y económico al desarrollo del proyecto, las cosas han cambiado (al fin) a mejor: hace menos de un mes, el Sovereign Tech Fund (un organismo financiado por el gobierno alemán a raíz, precisamente, de la polémica en torno a Log4Shell) anunció su apoyo económico (596.160 €) al desarrollo de Apache Log4J.
Así, anunciaron que se garantizaría el respaldo a tres mantenedores del proyecto ("dos de ellos dejarán sus puestos de tiempo completo para hacerlo"):
"Hasta ahora [septiembre de 2023], los mantenedores principales no habían recibido apoyo financiero sustancial para su trabajo crítico de código abierto".
"A pesar de la atención generalizada y las preocupaciones sobre las vulnerabilidades de Log4J, esta es la primera vez que un colaborador clave, Christian Grobmeier, recibe respaldo financiero por su dedicación a proyectos críticos de código abierto".
En Genbeta | Los programadores Linux corrigen sus fallos mucho más rápido que los de Apple, Google y Microsoft
Ver 26 comentarios