Resumiendo, los pasos son los siguientes:
1: Modificamos el compilador C a una versión C' para que al compilar el programa X le añada una puerta trasera. De esta forma, estudiando el código fuente de X no se detecta la puerta trasera.
2: Obviamente, estudiando el código fuente de C' se puede ver que hace algo raro. Así que le añadimos una segunda modificación C", que lo que hace es que al compilar el código C le añada (al binario) las modificaciones de C'y C".
Ahora al estudiar el código de X no se ve nada raro, y al estudiar el código de C tampoco, pero al compilar X con C se le está añadiendo una puerta trasera, y al compilar C con C(realmente C") se le están añadiendo las modificaciones para que genere el X modificado y un binario del compilador también modificado.
En el artículo lo explican mucho mejor. Obviamente, no es tan sencillo, entre otras cosas porque hay que tener acceso al compilador utilizado , o porque la evolución del código del compilador o del código X puede hacer que los parches introducidos dejen de aplicarse bien...
Por otra parte, alguna vez he leído/oído de concursos de programación "oculta" (o no sé muy bien como llamarlo), que consisten en hacer un programa que haga la tarea A y la tarea B, pero que al estudiar el código solo sea evidente la tarea A. Aunque bueno, veo que de esto ya dice algo el artículo (el de la noticia, no elque he puesto yo
#12 Y el trafico de red usado por el backdoor (cuando se use) como lo camuflas??? Se puede detectar incluso desde fuera del propio host (mediante sniffers, cortafuegos u otras medidas tipo ids/ips, etc...) donde reside el backdoor (puestos a la paranoia, claro).
#13 Esteganografía.
Por ejemplo, cada vez que se deecte trafico de unbanner de publicidad, se redirige a un servidor controlado. Si usas una conexión SSL será más fácil de ocultar.
O si tienes poder para convencer a lso grandes, como Facebook, Apple o Goole, envías los mensajes en sus flujos de datos, que van cifrados.
O la de opciones que habrá que a mí no se me cocurren.
No digo que sea fácil, sobre todo porque cambiar el compilador de todos los mirrors de una distribución, y de todos los desarrolladores oficiales no tiene que ser nada fácil. Igual activando la característica al cabo de 3 ó 4 versiones.... Solo digo que las posibilidades están ahí.
De todas formas, una vez llegados a este punto, da igual que se trate de código libre o no; hay que aplicar las mismas técnicas heurísticas. Y si en base a estas técnicas defiendes que en un sistema operativo de código abierto no puede haber un backdoor, entonces supongo que dirás lo mismo de los sistemas operativos de código cerrado: en los dos casos puedes observar las entradas y salidas, y en los dos casos puedes desensamblar el código (aunque si que es posible que al sistema de código cerrado le hayan añadido una(s) capa(s) extra de obfuscación para dificultar el desensamblado.
#14 la diferencia es que en un sistema de codigo cerrado tu no sabes ni puedes saber como se implementan todas las fuciones del kernel a bajo nivel y estas mas limitado en poder por ejemplo configurar o limitar o modificar funciones del kernel o de sus distintos subsistemas. Todo esto realizado por gente con cierto nivel, claro.
"Supongamos que alguien decide analizar exhaustivamente el código para verificarlo. Si recordáis hace poco en el blog hablábamos de una iniciativa de financiación colectiva sólo para auditar el código de Truecrypt. Imaginaros el coste de auditar una distribución Linux cuyo código es más de 10 veces mayor."
No lo veo comparable del todo, truecrypt es encriptación bastante hardcore, ahí no hacen falta solo buenos programadores sino tambien buenos matemáticos para auditarlo. Además Truecrypt en particular no es código "abierto", tiene una licencia bastante restrictiva con la que menos developers se habrán inclinado a revisarlo que cualquier otra cosa. https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
No, es completamente imposible. Las puertas traseras únicamente pueden funcionar en código de licencia propietaria, en caso contrario se quedan cerradas y no dejan entrar al atacante.
De hecho hay muchos grupos de investigación tratando de convencer a esas puertas que se abran bajo otras licencias pero de momento sin ningún éxito.
#4 No se le pueden poner puertas al software libre, imaginate que alguien la cierra sin querer y ya no es lo suficientemente libre, ¿Quien sabría que pasa detras de la puerta? ( sería tan privativo que despertaria las iras de Stallman y la "comunidad" del anillo)
Nadie detectó el error a pesar de que el código estuvo siempre disponible. Sé que son casos aislados pero son ejemplos de que es factible que a la "comunidad" se le pase algo de este estilo por alto.
#7 Pero un bug no es un backdoor. Es decir, un bug es un error que por la razón que sea te permite hacer algo. El backdoor se pone a proposito, el bug no.
Yo lo veo bastante improbable. Existe mucho control de los repositorios de software libre en las distribuciones y en los paquetes originales mediante herramientas de control de versiones, firmas hash, etc...
Además estan luego los desarrolladores que auditan y mejoran el codigo, cambios de versiones de esos paquetes en las que se añaden nuevas funciones o se quitan/depuran antiguas, empresas u organismos que auditan el codigo aleatoriamente con distintos fines (aunque sean estadisticos o didacticos), etc etc etc.
Luego ademas se dispone de un arsenal de mecanismos de depuracion tanto del kernel como de control total sobre las conexiones/sockets, etc... que se pueden usar para detectar cualquier tipo de comportamiento extraño en paquetes/kernel y permitirian localizar un backdoor de forma no muy complicada.
También se tienen muchas medidas de seguridad como los parches del kernel tipo Grsecurity/SELinux/RSBAC, firmas de ejecutables o binarios, etc...
Estoy seguro que muchos hackers/desarrolladores de Linux encontrarian este tipo de software tarde o temprano y se podria trazar el origen y/o responsable de su introduccion o del descuido por el que se pudo introducir.
Es muy distinto un bug de una puerta trasera intencionada (pero que muy distinto).
Comentarios
#5 El kernel se puede compilar perfectamente sin los blobs propietarios.
si, pero a medio plazo alguien lo descubriria, seguro.
#3 ¿Incluso si está en los drivers privativos de los que habla?
#4 WTF.
En este artículo explican como hacerlo: http://cm.bell-labs.com/who/ken/trust.html
Resumiendo, los pasos son los siguientes:
1: Modificamos el compilador C a una versión C' para que al compilar el programa X le añada una puerta trasera. De esta forma, estudiando el código fuente de X no se detecta la puerta trasera.
2: Obviamente, estudiando el código fuente de C' se puede ver que hace algo raro. Así que le añadimos una segunda modificación C", que lo que hace es que al compilar el código C le añada (al binario) las modificaciones de C'y C".
Ahora al estudiar el código de X no se ve nada raro, y al estudiar el código de C tampoco, pero al compilar X con C se le está añadiendo una puerta trasera, y al compilar C con C(realmente C") se le están añadiendo las modificaciones para que genere el X modificado y un binario del compilador también modificado.
En el artículo lo explican mucho mejor. Obviamente, no es tan sencillo, entre otras cosas porque hay que tener acceso al compilador utilizado , o porque la evolución del código del compilador o del código X puede hacer que los parches introducidos dejen de aplicarse bien...
Por otra parte, alguna vez he leído/oído de concursos de programación "oculta" (o no sé muy bien como llamarlo), que consisten en hacer un programa que haga la tarea A y la tarea B, pero que al estudiar el código solo sea evidente la tarea A. Aunque bueno, veo que de esto ya dice algo el artículo (el de la noticia, no elque he puesto yo
#12 Y el trafico de red usado por el backdoor (cuando se use) como lo camuflas??? Se puede detectar incluso desde fuera del propio host (mediante sniffers, cortafuegos u otras medidas tipo ids/ips, etc...) donde reside el backdoor (puestos a la paranoia, claro).
#13 Esteganografía.
Por ejemplo, cada vez que se deecte trafico de unbanner de publicidad, se redirige a un servidor controlado. Si usas una conexión SSL será más fácil de ocultar.
O si tienes poder para convencer a lso grandes, como Facebook, Apple o Goole, envías los mensajes en sus flujos de datos, que van cifrados.
O la de opciones que habrá que a mí no se me cocurren.
No digo que sea fácil, sobre todo porque cambiar el compilador de todos los mirrors de una distribución, y de todos los desarrolladores oficiales no tiene que ser nada fácil. Igual activando la característica al cabo de 3 ó 4 versiones.... Solo digo que las posibilidades están ahí.
De todas formas, una vez llegados a este punto, da igual que se trate de código libre o no; hay que aplicar las mismas técnicas heurísticas. Y si en base a estas técnicas defiendes que en un sistema operativo de código abierto no puede haber un backdoor, entonces supongo que dirás lo mismo de los sistemas operativos de código cerrado: en los dos casos puedes observar las entradas y salidas, y en los dos casos puedes desensamblar el código (aunque si que es posible que al sistema de código cerrado le hayan añadido una(s) capa(s) extra de obfuscación para dificultar el desensamblado.
#14 la diferencia es que en un sistema de codigo cerrado tu no sabes ni puedes saber como se implementan todas las fuciones del kernel a bajo nivel y estas mas limitado en poder por ejemplo configurar o limitar o modificar funciones del kernel o de sus distintos subsistemas. Todo esto realizado por gente con cierto nivel, claro.
"Supongamos que alguien decide analizar exhaustivamente el código para verificarlo. Si recordáis hace poco en el blog hablábamos de una iniciativa de financiación colectiva sólo para auditar el código de Truecrypt. Imaginaros el coste de auditar una distribución Linux cuyo código es más de 10 veces mayor."
No lo veo comparable del todo, truecrypt es encriptación bastante hardcore, ahí no hacen falta solo buenos programadores sino tambien buenos matemáticos para auditarlo. Además Truecrypt en particular no es código "abierto", tiene una licencia bastante restrictiva con la que menos developers se habrán inclinado a revisarlo que cualquier otra cosa. https://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt
Si, claro
Ian Betteridge´s seal of approval
No, es completamente imposible. Las puertas traseras únicamente pueden funcionar en código de licencia propietaria, en caso contrario se quedan cerradas y no dejan entrar al atacante.
De hecho hay muchos grupos de investigación tratando de convencer a esas puertas que se abran bajo otras licencias pero de momento sin ningún éxito.
#4 No se le pueden poner puertas al software libre, imaginate que alguien la cierra sin querer y ya no es lo suficientemente libre, ¿Quien sabría que pasa detras de la puerta? ( sería tan privativo que despertaria las iras de Stallman y la "comunidad" del anillo)
A preguntas estupidas..
Claro que es posible, recuerden el bug en OpenSSL que pasó inadvertido por 2 años
https://www.schneier.com/blog/archives/2008/05/random_number_b.html
Nadie detectó el error a pesar de que el código estuvo siempre disponible. Sé que son casos aislados pero son ejemplos de que es factible que a la "comunidad" se le pase algo de este estilo por alto.
El artículo está muy bien.
#7 Pero un bug no es un backdoor. Es decir, un bug es un error que por la razón que sea te permite hacer algo. El backdoor se pone a proposito, el bug no.
Yo lo veo bastante improbable. Existe mucho control de los repositorios de software libre en las distribuciones y en los paquetes originales mediante herramientas de control de versiones, firmas hash, etc...
Además estan luego los desarrolladores que auditan y mejoran el codigo, cambios de versiones de esos paquetes en las que se añaden nuevas funciones o se quitan/depuran antiguas, empresas u organismos que auditan el codigo aleatoriamente con distintos fines (aunque sean estadisticos o didacticos), etc etc etc.
Luego ademas se dispone de un arsenal de mecanismos de depuracion tanto del kernel como de control total sobre las conexiones/sockets, etc... que se pueden usar para detectar cualquier tipo de comportamiento extraño en paquetes/kernel y permitirian localizar un backdoor de forma no muy complicada.
También se tienen muchas medidas de seguridad como los parches del kernel tipo Grsecurity/SELinux/RSBAC, firmas de ejecutables o binarios, etc...
Estoy seguro que muchos hackers/desarrolladores de Linux encontrarian este tipo de software tarde o temprano y se podria trazar el origen y/o responsable de su introduccion o del descuido por el que se pudo introducir.
Es muy distinto un bug de una puerta trasera intencionada (pero que muy distinto).