Ken Thompson llevaba 42 años teniendo razón. En 1984 publicó «Reflections on Trusting Trust», donde mostró que un compilador comprometido puede inyectar un backdoor en los programas que compila y, peor todavía, replicarse a sí mismo: si recompilas el compilador desde código fuente limpio, el binario resultante igual sale troyanizado. La comunidad trató eso por décadas como una amenaza de nicho, algo de «sí, en teoría, pero requiere tocar un compilador». Un paper nuevo en arXiv (2607.24888) acaba de romper esa comodidad.
Sin compiladores, gracias
El hallazgo clave: la técnica funciona con GNU strip, una utilidad de build completamente ordinaria que ni lee ni genera código fuente. Strip solo manipula binarios ELF ya terminados — borra símbolos de debugging, reordena secciones. Nada sospechoso. Y aun así, los autores construyeron un ataque trusting-trust completo alrededor de él.
El experimento se hizo sobre el bootstrap de NixOS, que es probablemente el peor escenario para un atacante: NixOS es famosa por sus builds reproducibles y por reconstruir casi todo desde un semilla binaria mínima. Basta un solo strip troyanizado en esa semilla. El payload se propaga de una generación de strip a la siguiente, sobrevive incluso después de que la semilla original sale del closure de dependencias, y termina implantado en casi todos los binarios del entorno estándar final. Lo demostraron construyendo un instalador gráfico completo, sin errores, con backdoor en casi todos sus paquetes.
Por qué esto me incomoda
Trabajo manteniendo servidores Linux a diario y mi modelo mental era: la cadena de confianza empieza en el compilador, así que si verifico el compilador (reproducible builds, binarios bootstrap verificables), estoy razonablemente bien. Este paper demuestra que esa hipótesis era falsa. Cualquier utilidad que toque binarios durante el build es un vector potencial. Y la lista de utilidades que tocan binarios en un build moderno es larga: strip, ar, ld, objcopy, patchelf, las que empaquetan.
Lo más engañoso del ataque es la persistencia fuera del closure. Uno asume que si la semilla binaria comprometida ya no es dependencia de nada, su efecto se diluye. Acá no: el payload muta de generación en generación de la herramienta, como el original de Thompson, y se re-implanta a sí mismo aunque la fuente de infección original desaparezca del grafo. Es parásito puro.
¿Qué se puede hacer?
El paper no deja todo perdido. Las defensas que ya existían para el ataque clásico siguen siendo relevantes, pero hay que ampliarlas:
Diverse Double-Compiling (DDC), la técnica de David A. Wheeler: compilar dos veces con compiladores distintos y comparar. Habrá que extenderla a las utilidades binarias, no solo al compilador. Reproducible builds ayudan a detectar divergencias, aunque como mostraron con NixOS —la distro reproducible por excelencia— no bastan solas si la semilla está contaminada. Y el trabajo de bootstrappable builds, que minimiza la semilla binaria de confianza, gana todavía más valor después de este resultado.
En lo personal, esto refuerza algo que ya le repito a quien quiera escuchar: la confianza en binarios precompilados es una apuesta, no una garantía. Cuando descargas una imagen de distro o un paquete, estás confiando en una cadena de cientos de herramientas y personas. El ataque de Thompson era el recordatorio teórico; ahora hay prueba de laboratorio de que la cadena es más frágil de lo que pensábamos, y que el eslabón débil puede ser una herramienta tan aburrida como strip.
El paper está en arXiv si quieres los detalles técnicos: Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation. Léanlo, aunque sea solo para perder un poco de fe en sus binarios. Es sano.
Fuente de inspiración: Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation
