È una vulnerabilità ben nota che un file binario del compilatore opportunamente modificato può trasferirsi ai nuovi binari del compilatore, ed essere ancora completamente assente dal codice sorgente.
Ma quanto è reale questa possibilità? C'è stato qualche tentativo di controllare i binari nei compilatori disponibili (gcc per esempio) per rilevare tali vulnerabilità auto-replicanti?
In realtà non è "ben noto". La storia proviene da un articolo da leggere assolutamente classico di Ken Thompson. Anche se è stato implementato in quel momento come dimostrazione, sarebbe difficile farlo su una scala più ampia.
Il problema principale qui riguarda gli aggiornamenti software . Perché il chunk binario dannoso venga reintrodotto nel compilatore, nel caso in cui il compilatore venga ricompilato con sé stesso, quel codice deve sapere dove, precisamente, dovrebbe agganciarsi. E questo può cambiare tra le versioni del compilatore. Quando uno sviluppatore GCC apporta alcune modifiche al codice sorgente, potrebbe involontariamente interrompere il meccanismo di aggancio dell'ipotetico virus replicante e non lo saprebbe. Ma i futuri cambiamenti da parte degli sviluppatori non possono essere previsti, né tanto meno essere considerati in un virus che deve quindi funzionare in modo autonomo.
Oppure, detto diversamente, riuscire a scrivere un pezzo di codice (malevolo) che resiste a più di 20 anni di aggiornamenti e revisioni di un software complesso come GCC, sarebbe un'impresa ingegneristica notevole, e dubito dell'intera umanità nel suo complesso ne sa abbastanza dei computer per riuscirci. Eppure.
Nella vecchia situazione di Thompson, il software del compilatore C non è stato modificato, ma solo ricompilato, e questo ha reso l'intera faccenda facile (un apripista divertente e filosoficamente impegnativo, ma ancora tecnicamente facile).
Leggi altre domande sui tag audit opensource binary-code