¿Sigue siendo una amenaza el hack de compilación de Ken Thompson?

¿Su truco original, en ese compilador específico? No. ¿Más generalmente? Sí.

El ensayo de Ken Thompson se titula “Reflexiones sobre confiar en la confianza”. El punto real de ese ensayo, si lo retira todo, es que en cualquier sistema que desee proteger, debe establecer una raíz de confianza verificable. Su truco demuestra que un compilador puede evitar que (de una manera muy nefasta) establezca esa raíz.

Podrías montar el ataque de Ken contra otro compilador. Cualquiera que sea el compilador que atacó Ken probablemente no funciona o el sistema ha cambiado lo suficiente como para que sus trucos de coincidencia de patrones ya no se activen. Pero, la técnica general es sólida.

Para establecer una raíz de confianza, debe asegurarse de que todos los niveles de la pila de software sean confiables. El compilador proporciona una capa de abstracción. Hay al menos una, si no dos capas de abstracción debajo del compilador y encima del silicio. (Esto supone que confiamos en el silicio).

El punto de Ken, en realidad, es que a menos que haya analizado toda la pila (es decir, la salida compilada y las bibliotecas que invoca), no puede confiar en que el código fuente que alimentó al compilador representa lo que realmente se ejecuta en el máquina. Y si construyes el mecanismo de subversión en el compilador, puede ser muy difícil de encontrar.

Y eso es porque la mayoría de la gente confía en el compilador. Es el nivel de abstracción más bajo con el que suelen lidiar. Desde una perspectiva de ingeniería social, infectar al compilador es muy poderoso, ya que casi nadie cuestiona al compilador. Es solo una herramienta. Sin embargo, lo que realmente deberían estar cuestionando son los desarrolladores del compilador.

_____________

EDITAR: Bruce Schneier hizo una publicación de blog hace algunos años que detalla una forma de detectar el ataque Trusting Trust. Es un enfoque simple: contrarrestar la “confianza de confianza”

Pero … tienes que hacer que la gente lo haga.

Seguro. ¿Cómo demostraría que estaba ausente en el compilador actual de GCC?

Tendría que tener un programa de análisis binario que resolviera lo que hacía cada bit del compilador GCC compilado, y convencerse de que ningún bit está insertando código malicioso. Dado que GCC es enorme, el código está altamente optimizado (por GCC mismo), y Turing hace que las cosas sean realmente difíciles de entender, tendrías que tener un argumento muy convincente de que puedes hacer todo esto para ser convincente. No creo que puedas producir tal argumento. Por lo tanto, usted / nosotros / todos los usuarios de GCC están en riesgo.

El mismo argumento para Microsoft / Clang / Greenhills / IBM u otros compiladores de C.

Su única esperanza es intentar compilar las fuentes de un compilador con otro, bajo el supuesto de que no hay dos compiladores que tengan exactamente la misma trampa. Dado que en gran medida no aceptan los dialectos del otro, esto probablemente no sea práctico. Un genio realmente malvado habrá contaminado a todos los compiladores principales para manejar la compilación cruzada, por lo que aún está en riesgo. (Puede que personalmente no tenga la energía para hacer esto, pero un estado-nación sí).

Si cree que el hack de reemplazo de inicio de sesión de Thompson es peligroso, considere la posibilidad de código oculto para compilar llamadas en procedimientos de encriptación para agregar registros para registrar las claves de encriptación. Ahora ninguno de sus datos cifrados está a salvo.

Puedes pensar en muchas más variantes desagradables. ¿Cómo los buscarías a todos? Por lo tanto, la situación es aún más aterradora de lo que sugeriría una lectura literal de su artículo.

Sí.

Tienes que entender que el truco de Ken está fuera del alcance del programa. No ve el código fuente u objeto de nada de lo que adjunta al prólogo o preámbulo de su programa compilado. No son grandes batidos. Depende de arrancar un compilador desde el primer ensamblaje / compilación y después de que no se adjunte nada que no conozca.

Escribí un artículo sobre programas aparentemente vacíos, qué tan grandes son y cuántas operaciones realizan (en algunos casos, millones para no ser nada). No esperes consistencia.