Texto-plano Marzo 2026 ===================================================================== Revista digital 06 | 02 --------------------------------------------------------------------- Las manos de UNIX! ~peron ===================================================================== El 12 de junio de 1974, un viejo Juan Perón salía al balcón de la Casa Rosada por última vez y pronunciaba aquello de "la más maravillosa música". EL país medio se iba al carajo, pero bue. Parecía que había tirado este comando: ``` ASCII-ART: Perón usando el comando cowsay peron@cgt:~$ echo "Llevo en mis oídos la más maravillosa música que / es para mí la palabra del Pueblo Argentino"|cowsay -f pocho _______________________________________ / Llevo en mis oídos la más maravillosa \ | música que es para mí la palabra del | \ Pueblo Argentino / --------------------------------------- \ \ ,_____._____ ,_. /-_---------_\ / | || || /\ / < \|.__. .__.|/ | l | / |E==< E==<| n J | | / G| | | |D \ | | | \| , q_p , |J _|__/_ ==== | /._____.\ | |\__/| | | ( \___J ) | | | | ( =.___- = ) / / | | (.__-___,) / / \ |____----+ |________/ / \ \ \/ _/ / \_____ \ / / ______/ ``` Lejos del bullicio y al mismo tiempo, en la Universidad de Utah, en los EE.UU., tiraba unos comandos de último momento en una minicomputadora DEC PDP-11/45. Cuando el plato dejó de girar, sacó el carrete 3A del cabezal de la grabadora de carrete abierto TU45, enroscó la cola de la cinta magnética de 9 pistas y 1 pulgada, y tras ponerle el estuche protector con una etiqueta mal escrita, la metió en una una caja de cartón, a la que cerró con cinta marrón de embalar. La mandaron arriba de todo, al fondo del estante. Total, era una copia de seguridad de alguna de las computadoras del campus. Si alguien la necesitaba, la encontraría con todas las demás... Se trataba de una copia del código fuente que se necesitaba para recrear la imagen de la cuarta versión de lo que por entonces era "un sistema operativo de investigación": el UNIX. ``` ASCII-ART: Marcha con carteles de 'peron' y 'CGT' _____________________________ < stack overflow! Core dumped > ----------------------------- \ \ _______ \o/ \ peron \ --------- ------+ \------- | C G T | :::::::::::::::\::::::::::|---------|::::::::::: %%%%%%%%%%%%%%%%\%%%%%%%%%|%%%%%%%%%|%%%%%%%%%%% &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& oooooooooooooooooooooooooooooooooooooooooooooooo quit Goodbye >Al observar el código, algo que llama la atención es que la imágen quedó "congelada" el mismo primero de junio de 1974, mismísimo día del "último discurso de Perón". El desborde de pila en su.c El programa su nos convierte en superusuario o administrador, el famoso "root". Al ingresar la contraseña de administración, y el programa se encarga de revisar comparativamente el hash, y de coincidir, nos otorga un intérprete de comandos con la fuerza del Conductor: el root. Todo esto lo realiza el programa su, compilado a partir del código fuente su.c (ocupa menos de 50 líneas de código C ordenadito). ¿Todo ordenado? Bueno, no tanto. La cinta de 52 años, aunque perfectamente legible, reveló un bug de tal vez mayor edad: un desbordamiento de pila que tiene el mismo aspecto de los que encontramos hoy. Aquí reside el problema: char password[100]; while((*q = getchar()) != '\n') if(*q++ == '\0') return; El buffer de contraseña tiene 100 bytes. El bucle lee caracteres hasta que se lleva puesto un caracter ASCII de nueva línea. Pero no revisa si ya llenó los famosos 100 bytes. Si mecanografiamos más de 100 caracteres, podremos sobreescribirlos en la memoria adyacente a la pila de memoria. # su password: Memory fault -- Core dumped Se trata de un clásico desborde de pila provocado por el bufer, la madre de todos los bugs de seguridad informática. Doug McIlroy, quien gerenciaba al equipo de ciencia del cómputo en los Laboratorios Bell que programaron UNIX, se refería a este tipo de ocurrencias: "Los buffers desbordados eran comunes en esos días". En 1973, la seguridad no era una preocupación: las computadoras permanecían en habitaciones cerradas con candado, y eran manejadas por usuarios confiables. La idea de que alguien deliberadamente quisiera desbordar un buffer para explotar una falla de sistema no le entraba en la calva de Ken Thompson ni pasaba las barbas de ninguno de los Magos UNIX que lo rodeaban. La primera explotación de un desborde de buffer llegó unos 14 años más tarde. El Gusano Morris de 1988 empleó la técnica de desbordar el buffer del demonio del programa finger (fingerd) para infectar unas 6.000 computadoras, unas 10% del total de la masa informática con vínculo a la Internet en el momento. Aún cometemos los mismos errores. En enero de 2021, el bug CVE-2021-3156 demostró un desborde de buffer saltarín en el programa de escalado de derechos a superusuario del Linux, el sudo, que estuvo metido en el mismo durante casi una década. En junio del 2025, el CVE-2025-32463 demostró afectar a sudo nuevamente, escalando privilegios por izquierda, mientras que CVSS 9.3 lo explotaba activamente de forma práctica. Unix v4 venía con el código fuente al completo y el compilador de C de Ken y Dennis. Podías emparchar y recompilar el sistema entero por vos mismo sin necesitar otro herramental. Este parche agrega un contador que fisgonea la cantidad de caracteres que ha leido la entrada: + register int i; q = password; - while((*q = getchar()) != '\n') + i = 0; + while((*q = getchar()) != '\n') { + if (++i >= sizeof(password)) + goto error; if(*q++ == '\0') return; + } Tras compilarlo, moverlo a /bin/su, poner el bit setuid para hacerlo ejecutable, y ya tenemos un sistema emparchado. El investigador que escribió este parche intentó inicialmente un puntero aritmético, que sería la forma normal para hacerlo en el ANSI C más moderno, pero el compilador de 1973 dinosaureaba herbívoramente, aceptando la sintaxis sin chistar pero sin generar un código objeto útil, así que tuvo que hacerse con una revisión más simple basada en índice. Por supuesto, UNIX v4 no tiene redes TCP/IP ni ninguna otra (esta aparecería con el 4.3BSD en 1983). Por tal motivo, no se podría explotar la falla remotamente, pero la misma clase de bug en software de red ha causado gravísimos daños a través de las décadas. El modus operandi no ha cambiado. En los primeros 16 días de enero de 2025 solamente, aparecieron publicados 134 nuevos CVEs en el kernel de Linux, señal de la rápida carrera armamentística en la explotación de bugs de kernels tontamente escritos - como lo es Linux, claro está. En consecuencia de ellos, se han conocido más de 21.500 vulnerabilidades en la primer mitad del 2025, afectando todo lo que va desde kernels a controladores, pasando por servicios de sistema. Los desbordamientos de buffer existen porque C te deja escribir en memoria más allá de los límites fronterizos de los arrays, sin advertencia, y la solución es la revisión de los límites de memoria -algo que se puede hacer con herramientas ya hechas, y seguras- pero aún así los programadores siguen olvidándolo. * 1973: Se revisan los límites de memoria en el fichero fuente su.c * 1988: El Gusano Morris explota el desbordamiento de pila en fingerd. * 1997: Un error similar de syslog se reporta en la libc de Linux. * 2001: Code Red usa desbordamiento de búffer en IIS, y desbarata 359.000 sistemas Window$ en 14 horas. * 2021: Una vulnerabilidad en sudo permanece sin detectar por más de una década. * 2023: "Looney Tunables" - un desborde de búfer en el cargador dinámico de glibc, otorga acceso de root completo. * 2024: Desborde de salto en glibc syslog() - el mismo tipo de bug que el de 1997, el mismo error en código nuevo. * 2025: sudo cae de nuevo (CVE-2025-32463), escalado de privilegio crítico, CISA KEV * 2025: Vulnerabilidad en el kernel de Window$ (CVE-2025-24990), explotada activamente en campo. Esto es tres generaciones de programadores tanto de Window$ como de Linux, todos cometiendo los mismos erroes. El bug syslog de glibc de 2024 es casi idéntico al reportado en 1997, y 25 años después, alguien cometió el mismo error exacto en código fuente más nuevo. Existen lenguajes más seguros con la memoria, pero la infraestructura más crítica aún corre en C, y lo hará por décadas. 52 años después, aún encontramos los mismos bugs en código diferente. La historia no se repite, pero a veces rima. =====================================================================