Un binario strip manipulado puede colar una puerta trasera en todo NixOS

El ataque trusting-trust siempre se ha descrito como un problema de compiladores. Un artículo en arXiv demuestra que no lo es. Cinco investigadores construyeron una versión completa del ataque alrededor de GNU strip, una herramienta de compilación que nunca lee ni escribe código fuente. Con ella colaron puertas traseras en casi todos los binarios de un instalador gráfico de NixOS.

Los autores son Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli y Théo Zimmermann. El artículo se publicó el 27 de julio de 2026.

Cuál era el ataque original

Ken Thompson describió la idea en 1984. Manipulas un compilador para que inserte una puerta trasera en los programas que construye. Además le enseñas a reconocer cuándo se está compilando a sí mismo, y a meter la misma manipulación en el compilador nuevo.

Después puedes borrar el código fuente malicioso. La puerta trasera sigue reproduciéndose en cada reconstrucción, y leer el fuente del compilador no revela nada.

La comunidad de seguridad trató esto como una amenaza propia de los compiladores. Esa suposición es justo lo que ataca el artículo.

Por qué strip cambia el panorama

GNU strip elimina símbolos de depuración de los archivos compilados. Nunca ve código fuente. Solo reescribe archivos ELF ya terminados, que es el formato ejecutable estándar en Linux.

Los investigadores metieron un strip manipulado en la semilla binaria de NixOS, ese pequeño conjunto de binarios precompilados con el que arranca una distribución antes de poder construir nada por sí misma. Desde ahí la carga se copia en cada nueva generación de strip.

Luego sobrevive hasta el entorno estándar final, después de que la semilla original haya salido del grafo de dependencias. El punto de partida manipulado ya no está, y la puerta trasera sigue.

Lo ejecutaron sobre una revisión real de nixpkgs, fef9403a3e4d, con GNU binutils 2.44 en x86_64. La compilación terminó sin fallos y produjo un instalador gráfico funcional con casi todos sus binarios comprometidos.

Las defensas que no lo detectan

Esta parte merece leerse con calma, porque las respuestas habituales fallan cada una a su manera.

Defensa	Por qué se le escapa
Diverse double-compiling	El ataque "sits on both sides of the comparison and cancels out"
Compilaciones reproducibles	Reconstruir con la misma semilla reproduce la carga bit a bit
Compilaciones arrancables	Ayuda solo en proporción a lo pequeña que sea la semilla binaria

El diverse double-compiling reconstruye un compilador con un segundo compilador independiente y comprueba que los resultados coincidan. Los autores señalan que "then checks that the two results agree", que es exactamente la comprobación que supera una carga presente en ambos caminos.

Las compilaciones reproducibles buscan "make every build produce bit-for-bit identical output", con un reconstructor independiente que confirma que un binario corresponde a su fuente. Una salida idéntica no es lo mismo que una salida limpia.

El artículo sí apunta a algo que ayuda. "The full-source bootstrap in GNU Guix reduces the binary seed to a few hundred bytes and rebuilds the whole toolchain from auditable source above it", escriben los autores. Una semilla más pequeña significa menos material no auditable donde esconderse.

Qué significa esto para los desarrolladores

Deja de identificar la base de confianza con el compilador. Cualquier binario de tu arranque que transforme otros binarios entra en el ámbito, y eso incluye strip, enlazadores, archivadores e instaladores. La mayoría de modelos de amenaza nunca los listó.

Si te apoyas en compilaciones reproducibles para tus garantías, entiende exactamente qué demuestran. Demuestran que tu compilación es determinista. No demuestran que tus entradas fueran limpias, y este ataque es deliberadamente determinista.

Si tienes NixOS en producción, separa lo que ha ocurrido de lo que no. El ataque lo demostraron investigadores sobre una revisión real, con un paquete de replicación publicado. No hay respuesta pública del proyecto NixOS, ni indicios de que nadie haya hecho esto fuera del laboratorio.

La palanca práctica es el tamaño de la semilla. Los pocos cientos de bytes de Guix son otro orden de riesgo que una semilla binaria convencional. Pide ese número cuando alguien te diga que su distribución es arrancable desde fuente. La gobernanza del código abierto ha tenido un año movido, desde la votación de Debian sobre contribuciones asistidas por IA hasta la disolución del equipo central de Nixpkgs. Esto recuerda que la cadena de compilación también necesita atención.