Linux, rdrand, la NSA y mierda en pala

Ya muchos blog han publicado lo suyo respecto al tema, mi idea no es profundizar en lo ya dicho, sino ser practico y dar mi opinion, o sea, lo que comunmente se llama “editorial”.
Al final del post, voy a poner unos cuantos enlaces que contienen lo que voy a comentar y sobre los que voy a opinar, porque si, lei todos.

Primero que nada, RDRAND es una funcion EXCLUSIVA de Intel a partir de Ivy Bridge, los que tengan hardware anterior o bien AMD, no deben preocuparse.

No se puede probar a ciencia cierta que realmente ese blob en el kernel Linux este backdooreado por la NSA; pero, frente a la duda, y frente a que Intel, en vez de decir “no señores, como se atreven a dudar de nosotros, tomen el fuente” solo da excusas, debemos dudar.

Ya deben conocer la historia del developer que se fue del grupo Linux dado que Torvalds decidio meter eso en el kernel por ser mas rapido o mejor que el generador de numeros random por software, pero el muchacho no queria y decia que era inseguro, porque el hardware y el codigo del mismo no podia auditarse, etc, etc.

Tambien conocemos la peticion online en change.org sobre que se retire del kernel y la respuesta de Torvalds, poco mas llamando idiota al que abrio la peticion.

Muchas son las posturas, y encontradas, tenemos por un lado del ring a Torvalds el cual no cree realmente que algo este sucio y defiende el hecho. Por el otro, tenemos a referentes como Theodore Ts’o que se encarga actualmente del generador random de Linux, ext FS y otras cosas, junto a Alan Cox, un ex empleado de red hat, que dicen que NO confian en el codigo de Intel y cada uno emplea su argumento.

Theodore por su lado dice que no puede estar seguro de que todo esta limpio porque no tiene el codigo, y sostiene que no se puede confiar en algo cerrado, de hardware ajeno para la base criptografica, por lo tanto, la actual salida de numeros random de Linux es un mix entre RDRAND de Intel y el generador por software, con lo cual, es imposible que haya un backdoor que funcione.

Por otro lado, tenemos a Alan Cox quien le responde en el hilo de Google Plus a una persona, diciendole que el no lo duda (el backdoor) y que tampoco le pareceria raro que el mismo RHEL este backdooreado, porque a la NSA tambien le gusta espiar a sus amigos (el servicio de inteligencia de UK GCHQ).

Al final, tenemos, un tarado confiado (Torvalds), y dos developer respetados desconfiados y uno argumentando que para el, RHEL incluso tiene backdoor.

Porque digo tarado a Torvalds?, bueno a ver, todos desconfian menos el, y eso me parece algo de tarado… ademas en una entrevista dijo, hace mucho, que para él la seguridad no era relevante, dado que era producto de bugs, y por lo tanto, era mas importante corregir bugs, y ademas de eso no queria que nadie tuviera el credito de nada o sea mas importante que nadie (por los security boys), cuando no es asi, por dedicarse a seguridad no son mas importantes, aunque en la vida real, un bug te puede joder algo, un bug de seguridad, te puede joder todo.

Bueno, ya dicho esto, vamos al punto, si tenes un CPU Intel Ivy o superior y no confias en el codigo RDRAND de Linux proporcionado por intel, en el cmdline del kernel, añadis: ‘nordrand’ sin comillas y listo.

Ahora bien, que opino yo?, bueno, teniendo como antecedente que alla por el 95 aproximademente, Intel queria meter algo en sus CPU para tener el control de cuantos CPU de ese modelo habia online (cuando conectabas la PC a inet) y se lo denegaron, no me extraña que si abiertamente querian hacer algo asi, por detras sea peor, y como viene la mano con la NSA, ya nada me extraña.

Porque Intel y no AMD?, bueno la respuesta es obvia, porque es el mayor proveedor de CPU en el mundo, mientras que AMD es minoria, asi que no solo era en vano meter un backdoor en CPU AMD sino que ademas, convencer a los developer de Linux de incluir algo de AMD tambien iba a ser costoso, imaginense que el cpu frecuency scaling no funciona en muchos APU de AMD… ya con eso digo todo, en referencia a la pelota que le da Linux a AMD y viceversa.

Asi que no es necesario no comprar Intel (dado que si, son mejores que los AMD; en portatil eh en desktop es tema de discusion), con solo usar ese parametro de kernel, TODO esta solucionado y si eso no basta, se puede eliminar el codigo rdrand.c y listo, a compilar el kernel.

Hay otro tema que me gustaria tocar, y es el tema de que curiosamente, mientras pasaba todo esto, Theodore, negó un parche de un developer de Red Hat, que basicamente lo que hacia es que si estaba presente la funcion de CPU RDRAND, anulaba el random por software que hacia el mix de la salida. Obviamente Theodore negó el parche por razones obvias, y le explicó el porque, que no se podia auditar, etc, etc, el developer de red hat se vio algo ofuscado.

Ahora bien, supongamos que las intenciones del developer era buenas, y no era un enviado de la NSA dentro de Red Hat, o Red Hat mismo aliado de la NSA (es curioso como se relaciona esto con el tema del soporte de Fedora a paises embargados, documentacion y material criptografico contenido… pero bue), de todos modos, es MUY idiota de parte del developer, por mas que no sea enviado de la NSA y por mas que el confie en Intel, basar toda la criptografia de un equipo Intel en algo de codigo cerrado, o sea, no tiene logica alguna.

Por lo tanto, sabiendo que ningun developer es tan pelotudo de hacer eso, por obvias razones, mas hablando de Linux, algo libre 100% auditable, es muy evidente que Red Hat tiene mucho que ver con la NSA, al menos para mi, se cae de maduro. Esto que pasó puso en evidencia a ese developer, tambien lo dicho por Alan Cox, y a eso le sumo el recelo que guarda Red Hat respecto a su software, incluido Fedora, con respecto a la ley de exportacion, como si aliado del estado fuera.

Creo que Torvalds y el mundo del software libre en general, deberian tomarse mas en serio la seguridad, no digo al punto de OpenBSD, pero si muy cerca. Incluso linux-libre posee el codigo de rdrand..

Ahora si, no los molesto mas, y les dejo algunos link interesantes para leer.

http://blog.jim.com/crypto/rdrand.html

https://plus.google.com/+LinuxMagazineEdici%C3%B3nenCastellano/posts/GWMuJhcUkrU


https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J


http://lamiradadelreplicante.com/2013/09/09/backdoor-en-linux-de-la-nsa-no-invente-senora/


https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J


https://lkml.org/lkml/2013/9/5/212 (Ingeniero de RH queriendo usar solo hardware de Intel)

Respuesta de theodore https://lkml.org/lkml/2013/9/5/415

http://arstechnica.com/security/2013/09/the-nsas-work-to-make-crypto-worse-and-better/


http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html

http://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-parameters.txt#n2117

Alan Cox se retracta – "Nunca dije cambiaría a Ubuntu"

Hace unas semanas, podiamos leer a Alan Cox, decir que Fedora 18 era la peor release de Red Hat y que iba a cambiar de distro.
Cuando le preguntaron en su cuenta de Google+, a que distro, el respondío, Ubuntu en uno de sus comentarios.

Hoy leo, que aclara y culpa a Slashdot (?) por el error/malentendido, que el nunca dijo eso… cuak, epic fail, sino que usaba y usa Ubuntu en una VM para el desarrollo de Android, pero que posee varias distro instaladas, entre ellas Fedora y que su goldfish es un Debian hacked.

Dear Slashdot, switching one system that run Ubuntu in a VM to Fedora into running Ubuntu does not constitute ‘switching to Ubuntu’. I’ve been running Unbuntu for some jobs (like building Android images) for ages 8). In fact I run several distros (Fedora still included)

And for that matter my goldfish boot/stress test image is a hacked Debian fs image…

Que decir… sin palabras, mas que… un mensaje para Alan:

Alan, antes de embarrar la cancha, fijate si existe una opción mejor, sino, mejora la que tenés, no te parece?.