Log4j es una biblioteca de software de código abierto escrita en Java y creada por la Fundación de Software Apache, que ha resultado muy empleada por muchos programadores en sus proyectos. Esto se entiende ya que ha resultado especialmente útil, como marco lógico (“framework”) de apoyo en el desarrollo de código de sistemas. Fue concebida a finales de los 90’s para facilitar la instrumentación de servicios de entrada (“loggin”) a servidores web así como su traza; de allí sus iniciales que recuerdan la idea de disponer de líneas programadas para realizar un “log-in for java”. Ha progresado en ampliaciones y mejoras, al igual que tiene derivados en numerosos lenguajes como son C, C++, C#, Perl, Phyton, Ruby y Eiffel, que facilitan a los desarrolladores el poder concentrarse en la lógica de sus aplicaciones y no desviarse, en las conexiones y compatibilidad con los Servidores Web; ofrece además una gran versatilidad para complementar programas en un modo tradicional, como es una interfaz de invocaciones (API) que se provee en XML o en Java y, últimamente, asiste también el trabajo de ingenieros de software que operan con la idea de construir sus productos web, como parte de una arquitectura soportada con módulos de componentes incrustados (“plugins”).
Hasta aquí todo luce de maravillas, pero la noche de terror empezó el pasado Jueves 9 de Diciembre, cuando se hizo público una vulnerabilidad en su interior que reportó un equipo de Microsoft. La dificultad ya tiene correcciones preliminares, pero aún está en estudio profundo y todavía se descubren otros perjuicios; se trata de una falla de programación que ya fue apodada en el argot técnico como “Log4Shell”, un sarcasmo del tipo “entrar para ser recibido con todo a tu favor” y cuyo centro luce muy vinculado con intrusiones basadas en objetos y nombres, que no se resolvían apropiadamente y que aprovechan las características de procesamiento de directorios de redes de computadoras, implementadas con el apoyo de la API llamada JNDI. Esto faculta a los delincuentes para que puedan ejecutar código remoto, en otras palabras “Señor criminal, inocule usted el programa que desee en el servidor que escogió como blanco de su fechoría y ponga a correr sus propias instrucciones a su antojo. ¡Que se encomienden a Dios el resto!”.
“La moraleja es obvia. Usted no puede confiar en un código que no creó usted mismo por completo. (Especialmente en el código de compañías que emplean a personas como yo). Ninguna verificación o escrutinio a nivel de código fuente, lo protegerá del uso de código que no sea de su verdadera confianza.”
Ken Thompson (1984)
Lo más llamativo del hecho es que ya hay reportes documentados de atacantes aprovechándose de esta falla, desde una variedad de continentes sobre diversos sistemas y que estarían perjudicando a una amplia gama de funciones, como es por ejemplo la criptominería. Los efectos del daño son también amplios, ya hay noticias de despliegue de infecciones con ransomware, sistemas IoT en problemas, redes automatizadas de robots (botnets) propagando el problema, realización de ataques de negación de servicios (DoS) y otros casos más. Lo que se aprecia a primeras es que los proyectos que se construyeron con “log4j”, han quedado expuestos, tras heredar la debilidad y como son numerosos, hay que corregir a cada uno de ellos. Ello tomará tiempo han dicho algunos, incluso meses y hasta podría ser que años. Es un trabajo monumental pero con un recordatorio incluso más inquietante para los profesionales del área, es decir, algo que les trae a la memoria los cuentos de arqueólogos enfrentando una maldición tras abrir alguna tumba de cierto faraón egipcio. Se trata del trasfondo que subyace en esto y que toca propiamente a la industria del software, a su columna vertebral, a su proceso de desarrollo en sí; en otras palabras a las concepciones y premisas prácticas que sostienen la ingeniería de construcción de software de nuestros tiempos.
Nuestros sistemas web del momento son complejos, heterogéneos, con cientos de miles de instrucciones, a veces millones y con frecuentes ejecuciones entrelazadas de componentes. Hay que agregar que comúnmente combinan tecnologías diferentes y operan en un ambiente inseguro y distribuido, como es la Internet. Se trata de sistemas con una estructura que abruman a un único individuo y por ello demandan la colaboración coordinada y estructurada de grupos, conocedores del tema y que con frecuencia se asocian por meses seguidos para poder cumplir con las metas y cronogramas estipulados, así como para reducir costos y alcanzar los objetivos buscados. Les resulta típico incorporar bibliotecas de funciones de programas de otros especialistas o empresas. Nos apoyamos en programas de otros conocedores, cual hacen muchas otras ingenierías, pero el asunto que resalta es que nuestro tangible se ejecuta en máquinas en un modo que a menudo no apreciamos y lo que si vemos son interfaces, también los efectos directos que producen nuestra órdenes. “¿Corre bien?” es la pregunta común del área y para ello colocamos protocolos de pruebas y etapas de observación y recopilación de experiencias, que nos indican si el resultado es bueno o malo. No sucede aquí como muchas veces le acontece a un ingeniero mecánico, por ejemplo, que puede ver una pieza que otro profesional le hizo y con una simple observación, podría notar un defecto en su forma. Ese ingeniero puede detectar con cierta facilidad si algo no encaja bien o suena extraño. En el caso de la ingeniería en computación, varias veces los diseñadores o programadores prueban sus productos, pero no aplican exhaustivas comprobaciones a los componentes que sostienen todos sus sistemas. ¿Hay tiempo, dinero e interés en examinar con ojo de auditor todas las bibliotecas y herramientas que permiten elaborar un sistema?, ¿se examinan cada uno de los compiladores, interpretadores o traductores?, ¿se inspecciona cabalmente la plataforma de software, a nivel operativo, de comunicaciones o de máquina virtual, que será la infraestructura de sostén del sistema?, ¿se buscan efectos emergentes o colaterales de cada rutina de software que no fue programada en casa? La respuesta común es no. No es rentable y se ha preferido apelar por el esquema del parche correctivo de software. Cuando se identifique se arregla.
De modo que hay un talón de Aquiles y es que el problema no lo hayas producido tú, pero que viniendo de uno de los componentes que usas, su perjuicio se transfiera a tu producto. Algo como “el jugo sabe mal, ya que había unos mangos pasados que se te colaron al hacerlo”. Y este problema lo advirtió, en 1984, el ganador del premio Alan Turing, el estadounidense Ken Thompson, uno de los creadores de Unix. Thompson sorprendió a muchos con un discurso que no relataba las maravillas del sistema de operación que le había hecho ganar el mayor premio en computación del mundo y en su lugar, prefirió alertarnos sobre algo del futuro de la programación. En una época donde todavía se podía hablar de sistemas de código “moderadamente grandes”, el visionario se enfocó en la confianza que ya depositábamos sobre la confiabilidad de otros programas. Y nos dijo que temía sobre cómo nos estábamos enfocando en eso.
Y esto no quiere decir que las bases teóricas de la ingeniería en desarrollo de software estén todas mal, ni nada así de extremista, tampoco es la primera crisis del área; más aún de seguro se superará. Lo que significa es que las prácticas de la industria no son perfectas y están lejos de estar completas, demandan mayor trabajo. El mensaje no es que los métodos y mecanismos de desarrollo de software no produzcan resultados favorables, es que nuestra atención ha estado más dirigida a la funcionalidad, que a la seguridad. Pero que en este mundo donde la ubicuidad y penetración de la computación se ha extendido por encima de lo que sus pioneros pensaron, donde dependemos cada vez más de sistemas automatizados, interconectados, multioperativos, con respuesta en tiempo real, la protección y confiabilidad ya no es un requisito del tipo cenicienta, algo marginado. Este es un mundo donde la computación hace rato escapó del control de los graduados en el área, donde muchos programan sin acreditaciones o certificaciones reconocidas, incluso donde las máquinas ya se programan a sí mismas con el apoyo de la IA. Es una realidad donde los incidentes globales que nos golpean en la cara, están resultando costosos de superar y pueden ir en aumento. Nuestra economía, banca, comercio, comunicaciones, clases, formaciones, diversiones, entretenimiento y hasta el vínculo con los estados, se afianza con la incorporación de un celular inteligente en manos de cada ciudadano.
Un ambiente donde a las aplicaciones se les accede desde la Internet y donde nuestras informaciones inmediatas y memorias de sucesos, para bien o para mal, las almacenamos y trastocamos con ejecuciones colectivas sobre medios distribuidos. Tal vez ya pasamos del medio es el mensaje, al contenido se distribuye por cualquier medio, sea este legal o ilegal; es un planeta más atractivo pero también mucho más peligroso. En consecuencia, lo que se refleja ahora es que hay espacio y hasta necesidad, para plantear otras vías, comparar y repensar en algunos casos nuestros fundamentos científicos o esquemas básicos de la disciplina de desarrollo de software. Y es que puede ser que, lamentablemente a golpes, ya estemos comprendiendo la vieja reflexión del genial Thompson, por lo que el asunto de atención ahora es qué de bueno resultará de nuestras respuestas.
Miguel Torrealba S. – Universidad Simón Bolívar Departamento de Computación y Tecnología de la Información
