Es una vulnerabilidad bien conocida que un binario de compilador correctamente alterado puede transferirse a los nuevos binarios del compilador, y aún estar completamente ausente del código fuente.
¿Pero qué tan real es esta posibilidad? ¿Ha habido algún intento de auditar binarios en los compiladores disponibles (por ejemplo, gcc) para detectar dichas vulnerabilidades de autorreplicación?
En realidad no es "bien conocido". La historia proviene de un artículo clásico de lectura obligada de Ken Thompson. Si bien fue implementado en ese momento como una demostración, sería un desafío hacerlo en mayor escala.
El principal problema aquí es sobre actualizaciones de software . Para que el fragmento binario malintencionado se reinyecte en el compilador, si el compilador se compilara consigo mismo, ese código debe saber dónde, precisamente, debe engancharse. Y esto puede cambiar entre las versiones del compilador. Cuando un desarrollador de GCC realiza algunos cambios en el código fuente, puede romper el mecanismo de enganche del hipotético virus de replicación, y no lo sabría. Pero los futuros cambios de los desarrolladores no se pueden predecir, y mucho menos se deben tener en cuenta en un virus que luego debe funcionar de manera autónoma.
O, dicho de otro modo, tener éxito al escribir un fragmento de código (malicioso) que resiste más de 20 años de actualizaciones y revisiones de un software tan complejo como GCC, sería una notable hazaña de ingeniería, y dudo que la humanidad en su conjunto Sabe lo suficiente sobre las computadoras para lograrlo. Sin embargo.
En la situación anterior de Thompson, el software del compilador de C no se cambió, solo se volvió a compilar, y eso hizo que todo fuera fácil (un revelador divertido y filosóficamente desafiante, pero aún técnicamente fácil).
Lea otras preguntas en las etiquetas audit binary-code opensource