¿Qué pasaría si alguien piratea el lenguaje de programación C? ¿Qué pasa si piratearon los compiladores?

Editar: La pregunta original se hizo sobre el lenguaje, no sobre los compiladores. Nota para el OP: Es * RUDE * cambiar los detalles solo porque no está de acuerdo con las respuestas que recibió.

No es posible hackear (es decir, subvertir la seguridad) de un lenguaje de programación. Puede hackear programas escritos en un idioma en particular, pero los idiomas, en sí mismos, son imposibles de hackear … tan imposible que ni siquiera está claro qué significa “hackear” un lenguaje de programación.

Dado que hay muchas implementaciones diferentes de compiladores de C (Lista de compiladores) y varias bibliotecas (Bibliotecas de programación / estándar de C), de todos modos sería muy difícil hackearlos.

Además, si C fuera “pirateado” de alguna manera, las personas simplemente cambiarían a un lenguaje diferente, como ya lo han hecho para la mayoría de la programación a nivel de aplicación.

Entonces, C es diferente a otros lenguajes con los que puede estar familiarizado, como PHP, Python, JavaScript, Ruby o incluso Java, que son lenguajes que tienen algún tipo de máquina virtual o intérprete que está escrito en código. En estos casos, uno podría “piratear el idioma” poniendo código malicioso en el intérprete y haciendo que se libere este código. Debido a que el intérprete es sinónimo del lenguaje de algo como Ruby o PHP, se podría decir que está pirateando el lenguaje.

En el caso de C, el compilador de C convierte el código que escribe en lenguaje de máquina, que es el nivel más bajo que la computadora entiende cómo procesar en la CPU. A su vez, la CPU convierte el lenguaje de la máquina en pulsos eléctricos en los circuitos sin procesar del hardware.

Podría comprometer el compilador de C como los intérpretes anteriores, pero no afectaría ningún código en la naturaleza a menos que / hasta que se vuelva a compilar ese código. Por el contrario, los idiomas de los intérpretes se verían afectados durante el tiempo de ejecución.

La conclusión es que el impacto sería bajo si explotara el compilador de C en comparación con el JVM o el intérprete subyacente de Ruby.

No puedes hackear un lenguaje, el lenguaje C es una especificación , no un producto o programa.

Puede modificar todos los compiladores de C en uso, para producir código con fallas de seguridad, pero necesitaría hacer que la gente realmente use esos compiladores y envíe el código compilado con ellos, sin darse cuenta de que hay un problema.

Aunque estoy de acuerdo con la mayoría de las respuestas aquí, creo que lo que realmente pretende preguntar aquí es qué sucede si alguien descubre una vulnerabilidad muy extendida en el código escrito en C que afectaría a casi todo el código escrito en C.
Las posibilidades de que esto suceda son realmente bajas, principalmente porque C ha existido por un * MUCHO * tiempo, y se han descubierto muchas vulnerabilidades.
Si tal cosa sucede, alguien u otro lo descubrirá pronto. La mayoría del software se parcheará realmente, y todo esto supone que es un error muy grave.

No puedes hackear un idioma. Eso no tiene sentido, ya que es simplemente una especificación. Pero puedes hackear el compilador.

Ken Thompson había escrito un artículo sobre la piratería del compilador de C, que creo que condujo a su premio Turing.

Una modificación simple al compilador que deliberadamente compilará mal la fuente cada vez que coincida un patrón en particular. Si esto no fuera deliberado, se llamaría un “error” del compilador. Como es deliberado, debería llamarse “caballo de Troya”.

El error real que planté en el compilador coincidiría con el código en el comando “iniciar sesión” de UNIX. El código de reemplazo compilaría mal el comando de inicio de sesión para que acepte la contraseña cifrada deseada o una contraseña conocida en particular. Por lo tanto, si este código se instalara en binario y el binario se usara para compilar el comando de inicio de sesión, podría iniciar sesión en ese sistema como cualquier usuario.

El paso final simplemente agrega un segundo caballo de Troya al que ya existe. El segundo patrón está dirigido al compilador de C. El código de reemplazo es un programa de autorreproducción de Etapa I que inserta ambos caballos de Troya en el compilador. Esto requiere una fase de aprendizaje como en el ejemplo de la Etapa II. Primero compilamos la fuente modificada con el compilador de C normal para producir un binario con errores. Instalamos este binario como el C. oficial. Ahora podemos eliminar los errores del origen del compilador y el nuevo binario los volverá a insertar cada vez que se compile. Por supuesto, el comando de inicio de sesión permanecerá molesto sin dejar rastro en la fuente en ninguna parte.

Para los más inteligentes, aquí está el artículo: https://www.ece.cmu.edu/~ganger/

Pensé en la idea un segundo pensamiento.

SI alguien pudiera obtener código malicioso comprometido en un compilador de código abierto popular como gcc. (Que debería ser casi imposible)

Todos los que usan dicho compilador podrían compilar algún código malicioso en sus programas. Este sería un logro importante y con una ingeniosa ingeniería del código malicioso se podría crear mucho alboroto. Pero en general, podría conducir a un evento de virus pandémico en el peor de los casos, pero nada más.

Es importante recordar que solo los lenguajes como C que se describen completamente en tiempo de compilación son imposibles de hackear.

Cualquier cosa con componentes de tiempo de ejecución, como Java, Python, C ++. etc., todos son posibles de piratear. Esto se debe a que tienen que cargar datos externos y ejecutar un ejecutable externo que es difícil de validar en tiempo de ejecución. Los compiladores de C son fáciles de validar antes de ejecutarlos. Está ejecutando activamente el compilador de C en lugar de que se ejecute automáticamente como un lenguaje de script.

Ken Thompson presentó lo siguiente al ganar su Premio Turing con Dennis Ritchie:

https://www.ece.cmu.edu/~ganger/

Es endiabladamente difícil de resolver.

Contrarrestar “Confiar en la confianza”

No puedes hackear un lenguaje de programación. Puede instalar una puerta trasera en un compilador, y luego básicamente puede hacer cualquier cosa. Por otro lado, tendrá dificultades para hacerlo con cualquier compilador que sea ampliamente utilizado.