Linux pudo haber incluido en su generador de números aleatorios una puerta trasera de la NSA [ENG]

En español → https://plus.google.com/+LinuxMagazineEdici%C3%B3nenCastellano/posts/GWMuJhcUkrU Puede que, con la inclusión de un parche, Linus permitiese que Intel colara una puerta para la NSA en el Kernel. Matt Mackall (dimitió por negarse a introducir el cambio): "Mientras tanto mi desconfianza del generador criptográfico de Intel ha variado desde "paranoia profesional normal " a "preocupación legítima y real".

[#3 V13]

Stallman vuelve a tener razón ™

[#7 Slur]

#3 Totalmente, eso mismo pensé al leer que "no se le puede confiar algo así a Intel". Al paso que va la informática, los que lo tildaron en su momento de "paranoico" por defender la privacidad y no confiar en las empresas, tendrán que aprender de él.

[#11 Desactivado]

#9 El titulo esta bien creo yo. Tampoco tiene pruebas, pero vamos ... tiene toda la pinta de que la NSA esta implicada en el generador. Como dice #3 Stallman tenia razon.

[#12 Jakeukalane]

#11 ah sí, depende de como lo leas. Ya me había entrado el canguele.
Lo que quiere decir es que lo que se incluyó puede que tenga una puerta trasera, no que puede que se incluyera o no se incluyera.

[#14 Jakeukalane]

#11 Stallman todavía no se ha demostrado que no tenga razón.
¿Cómo edito la entradilla? Es mi segundo envío y ando despistado...

[#15 Desactivado]

#14 Al final del txto debe salirte una W naranja. Dale ahi. Pero vamos la entradilla esta bien creo yo

[#38 scalvo]

#3 Casi siempre ha tenido razón en sus opiniones Stallman, pero en este caso concreto, a qué te refieres?

[#40 Jakeukalane]

#38 En dar confianza a algo cerrado procedente de una empresa por encima de su rendimiento. La filosofía de Linus (cercana a la del Open Source, código abierto) choca en este punto con Stallman (FSF, GNU Project, software libre) puesto que si se siguiese la filosofía de Stallman se habría optado por la solución por software que, a pesar del peor rendimiento (supuesto en la noticia y de otros comentarios que he leído aquí) se puede auditar, mientras que el microcódigo de los chipsets de Intel, no. Por principio, a pesar de la aparente ventaja que tuviese, Stallman habría dicho no a lo cerrado (y lo dice continuamente), mientras que, cómo se ha visto, Linus ha preferido el rendimiento vs la-posibilidad-de-que-alguien-haya-metido-mano (aparte de que no se pueda mejorar).

[#57 scalvo]

#40 Teóricamente se podría prescindir de este generador de números aleatorios verdad? Y usar otro hecho a medida, aunque sea mucho más lento.

Por otro lado, esto me hace recordar como hace años gpg pedía que hiciéramos muchas cosas, escribir con el teclado, mover el ratón, etc... mientras generamos claves, y se tardaban mucho en generar. Ahora va mucho más rápido... Yo lo achacaba a mejores equipos, pero quizá tenga que ver con estos chips de intel....

[#64 avat_light]

#57 Me temo que siempre que haces un Math.random() en cualquier lenguaje, va a usar ese código o chip por pelotas.
Entonces con esto podrían acceder a información protegida por números aleatorio creada en cualquier parte de cualquier programa que ejecutes en tu ordenador.

[#285 Desactivado]

#64 ¿y como hacen entonces los amd o los intel pre ivy bridge que no tienen esa instrucción?

[#71 ElSev]

#57 los de BlackBerry siguen pidiendo mover el ratón al azar para generar el cifrado cuando activas el servicio, no se deben fiar de Intel....

[#106 outofmemory]

#40 Ein? la filosofía del Open Source es exactamente la misma que la del Software Libre. De hecho, son dos formas de hablar de lo mismo [1].Por mucho rendimiento que tenga, si no es auditable es totalmente contrario al Software Libre/Open Source.
[1] http://opensource.org/faq#free-software

[#283 Desactivado]

#40 La licencia de linux es gnu como la de hurd, cualquier sofware que lo utilice debe ser gnu y no puede incluir partes que no sean gnu.
el problema es que aqui estamos hablando de hardware y las licencias en eso tienen poco que decir.
¿acaso hurd no usa las instrucciones mmx o sse? y nadie dice que esté incumpliendo la licencia por eso.
Este no es un tema de licencias. Afecta igualmente a windows y mac y a cualquiera que use esa instruccion. lo de auditar el codigo vale de poco porque intel se la habría colado a microsoft apple o cualquiera que usase esa instrucción.
Por cierto ¿Alguien sabe si esa instrucción es una instrucción privilegiada? En teoría no tendría porque serlo ya que es una instrucción matematica. Porque si no lo es cualquier programa podría usarla sin pasar por el sistema operativo y la discursion tendría que irse mas hacia los compiladores, librerias y programas en general.

[#292 Jakeukalane]

#283 El problema es que no estamos hablando de los mismo. Ya sé que Linux usa una licencia GNU GPL. Pero si te fijas usa la versión 2, no la 3. Y eso es debido a divergencias entre la filosofía utilitarista del código abierto (que se solapa muchas veces y es muchas veces código libre) con la propia de la FSF (Stallman). A grandes rasgos lo que he dicho en mi comentario en #40 es perfectamente correcto, si bien no son posturas antagónicas sino más bien posturas filosóficas. Ahora bien, estas diciendo que por licencia no podrían incluir esto en el núcleo. Según cuentan comentarios más arriba son sets de instrucciones no públicas (osea que no es un blob tal cual), sin embargo sigue siendo igual de cerrado que un blob, y se incluyen blobs en el núcleo.

Esa es la divergencia que hablo. Linus quiere un núcleo que funcione y si hay que llegar a un acuerdo con quien sea para poder soportar más dispositivos/etc pues se incluye ese código, aunque se prefiriera que fuese libre. Aquí lo que pasa es que Stallman pasa del pragmatismo y la practicidad y simplemente se niega a que algo funcione mejor si tiene posibilidad de coartar la libertad del usuario. Su solución sería algo así como: "entonces hay que trabajar para hacer un equivalente libre mejor" (en vez de apoyar a algo cerrado ahora).

Y es por eso por lo que lo he comparado a Linus con el movimiento open source del que no es fundador ni gurú ni nada, pero en mi impresión se encuentra más cerca, a pesar de que el núcleo Linux sea casi en su totalidad software libre.

Saludos

[#44 Mancini]

#3 Ese tio sabe mucho, es un humano mamímefero bastante interesante, tanto como tu o como yo.

[#4 kumo]

Lo bueno de poder leer el código es que ese "pudo" puede confirmarse y solucionarlo o desmentirse y pasar a otra cosa

[#5 Desactivado]

#4 es la parte que no comprendo de la noticia, si tienen el código fuente del parche, que lo afirme o no.

[#10 Jakeukalane]

#5 Me equivocado con el título. Cuando pueda (sepa) lo cambio.

El título debería decir así.
Linux ha incluido en su generador de números aleatorios código que puede tener una puerta trasera de la NSA [ENG]

pero eso es muy largo... arghhh

[#17 Desactivado]

#10 no sólo es largo, sino que además cada envío tiene que tener uno distinto. si lo importante es el tamaño del titular, pon intitula simplemente «buh» todos tus envíos.

[#20 Jakeukalane]

#17 eh, no lo he puesto porque no cabe, no por otro motivo... además de que cuando he ido a editarlo no me ha dejado.

[#13 Jakeukalane]

#5 Es un https://es.wikipedia.org/wiki/Blob_binario, ese es el problema. Que es cerrado.

[#22 Desactivado]

#13 No es un blob, es hardware. El generador está integrado en el hardware de intel en vez de estar hecho con software. http://en.wikipedia.org/wiki/Hardware_random_number_generator

Al final todo se reduce a si nos fiamos de intel y usamos el hardware que ha creado o no.

[#23 Jakeukalane]

#22 Mmmm tenía entendido que era un blob que controlaba un hardware. ¿Sigo equivocado?

[#30 Desactivado]

#23 Es una nueva instrucción del procesador. Los detalles de implementación no son accesibles, probablemente es un alias para varias microinstrucciones hecho usando microcodigo de procesador. http://en.wikipedia.org/wiki/RdRand

#27 Que Linux usa si está disponible un generador de numeros aleatorios por hardware creado por intel que le pega varias patadas en rendimiento a cualquier implementación por software. El problema es que no se sabe si intel ha incluido backdoors en su hardware.

La verdad si estamos en ese plan, casi mejor que no compres hardware de Intel.

[#33 Jakeukalane]

#30 gracias por la aclaración.
#24 #4 #5 ↑↑↑

[#50 ArcadasDeBuenismo]

#30 Solo porque quede claro:
¿Esto significa (de acuerdo con el enlace de la wikipedia) que todos los procesadores de Intel desde el tiempo del 386 están afectados por esta instrucción del procesador?

[#60 Desactivado]

#50 En la wiki ya dice que se añadió en los Ivy Bridge que salieron en 2011. Pero que esta disponible para 32 y 64 bits.

[#70 ArcadasDeBuenismo]

#60 Si, lo he leido, me he moletado en leer esa entrada. La pregunta era si cualquier PC igual o superior a un 386 con linux instalado, usa siempre esa característica, o bien solamente está obligado a usarla cuando está tan integrada como en los micros que salieron a partir de 2011, o por el contrario puedes desactivar la opción de usar esa microinstrucción en el kernel.
Creo que el tema es suficientemente grave, porque no sirve de nada usar PGP, si la generación de claves no es realmente aleatoria.

[#75 Desactivado]

#70 En procesadores anteriores es imposible de usar. Y eso de obligado, depende del sistema operativo.

[#112 voldemort]

#50 #60 Efectivamente, se introdujo en Ivy Bridge.
El anuncio de Intel: http://software.intel.com/en-us/blogs/2011/06/22/find-out-about-intels-new-rdrand-instruction

[#86 FarK]

#30 En verdad sí que estamos en ese plan, y creo que no sin motivos
Vamos, que las últimas noticias sobre la NSA os parecerán menos escandalosas o inpensables que esta. A mi no, yo ya desconfío hasta de mi sombra.

A este ritmo pronto nos llegarán locos con sombreros de papel de plata gritándonos "¡ya os lo dijimos!"

[#288 pinger]

#30 a verdad si estamos en ese plan, casi mejor que no compres hardware

[#84 asdfg]

Linux no debería de incluir blobs en su kernel que no puedan ser auditados. Otro tema es el de los drivers propietarios en forma de modulos que cada cual se lo instala solo si quiere.
El truco que ya se ha comentado en sitios especializados consiste en generar números aleatorios predecibles ya que a día de hoy incluso la NSA necesita muchos años de mega-procesamiento para romper claves muy largas, con este parche reducen ese procesamiento a horas.



#23 No del todo, para que el kernel use ese "generador por hardware" viene acompañado de un parche en software. Y perdón por el negativo, le he dado sin querer.

[#93 avat_light]

#84 Eso tiene sentido.

[#36 gjulianm]

#4 #5 No es tan fácil. Incluso con el código, es muy difícil pillar una vulnerabilidad de este tipo aunque seas un gran investigador de criptografía. Quizás la relación entre los números aleatorios es tan sutil que es prácticamente imposible darse cuenta de que existe.

PD: Sé que el tema este en cuestión no tiene que ver con el software, pero era por aclararlo, que incluso teniendo el software y auditándolo no podrías estar 100% seguro de que es seguro.

[#66 Penetrator]

#36 No creo que sea tan difícil de detectar. No se puede auditar el hardware, pero sí se puede auditar el resultado utilizando herramientas estadísticas. Así a bote pronto se me ocurre que se pueden generar varios miles (o incluso millones) de números aleatorios con la dichosa instrucción, y luego analizar el resultado para comprobar que siguen una distribución uniforme, que no hay sesgos, que no hay números con probabilidades por encima de lo normal...

[#79 delawen]

#42 Bueno, se puede auditar parcialmente, si se usa hardware libre (o sea, de especificaciones libres).

Aunque precisamente un generador de números aleatorios no es algo que se pueda testear fácilmente (#66), el resto de funcionalidades sí podría auditarse que funciona conforme a la especificación del hardware libre.

Es el siguiente paso en la evolución natural hacia las libertades individuales: pasar del software al hardware libre.

[#87 scalvo]

#66 eso daría igual si en el chip hay info de cómo se generan las números.
#68 Eso sí es un ataque de fuerza bruta como dios manda... y lo demás son tonterías

[#130 Penetrator]

#87 ¿Información de como se generan los números? No entiendo lo que quieres decir.

[#83 Marx]

#4 #5 Independientemente de que sea código abierto o uno cerrado que no se puede auditar o un chip como aclaran algunos, supongamos que es código abierto que se puede auditar, aunque no sea cierto. Pues bien, ya lo dije en otro comentario: "Tú no puedes confiar en un código que no haya sido completamente creado por ti mismo. Ningún nivel de verificación o escrutinio te protegerá de usar código no fiable". http://cm.bell-labs.com/who/ken/trust.html Ken Thompson.

No es tan fácil.

Hay mucha fe ciega en el código abierto, en los miles de ojos y en la supuesta invulnerabilidad de linux contra virus y contra todo. Y a mi me cascan negativos por decirlo y nos metemos en eternos flames.

Tan sólo el kernel de linux tiene más de 15 millones de líneas. Ahora cuenta todo el software que está por encima y por debajo, cuenta la Bios, la UEFI y todo lo demás, incluso tu router y tu impresora de red ( http://www.elladodelmal.com/2013/09/la-nsa-prefiere-hackear-routers-y.html ) ¿todavía te sientes seguro por usar linux?

[#91 prejudice]

#83 No te sientes seguro. Te sientes un poco mas seguro.
Prefiero tener la incertidumbre de que mi sistema es seguro. A tener la certeza de que no lo es.
Esto es como el que dice que no quiere dejar el tabaco, por que hay gente que no fuma y muere de cáncer de pulmón. Si tu sistema no está formado por software libre, tienes mas papeletas para que tu sistema sea inseguro

[#95 Marx]

#91 Bueno, poco a poco vamos avanzando.

Pues yo no. Sé a ciencia cierta que me pueden espiar cuando quieran y que no soy más listo que una agencia gubernamental del país más fuerte del mundo con presupuesto de miles de millones de dólares y que tiene comprado a todo cristo.

Cuando sepa cómo evitarlos, entonces lo haré pero mientras ¿qué más me da que me espíen por un lado o por otro, como también lo hacen contigo? uso lo que mejor me sirva en otros aspectos y punto.

Edito: has editado. Esto más bien es como el que fuma tabaco porque sabe que si no muere de cáncer de pulmón por culpa del tabaco, morirá de cáncer de pulmón por culpa de cualquier otra cosa. Si vas a morir de cáncer de pulmón, al menos que sea por algo que te gusta.

[#150 prejudice]

#95 Si me van espiar, por lo menos que les cueste tiempo y dinero.
No es lo mismo perder, por ejemplo una semana entera de computación para romper un cifrado ssl y poder ver que haces mientras estás conectado por ssh a un servidor linux, qué hacerlo cómodamente con una puerta trasera ad-hoc de Windows

Qué existan ladrones capaces de romper cerraduras no quiere decir que haya de dejar de usarlas.

Esto es como sabes que te van a violar sí o sí, mejor llevar puesto un condón antiviolación, y que se joda también el violador

[#108 Marx]

#105 A lo primero: sí, ya se demostró con esto como alguien (Linus) metido en el desarrollo... dio el visto bueno a algo no seguro y como otro alguien también metido dimitió por ello pero... no nos avisó o nadie le escuchó. Para todo lo demás: #83

Para lo segundo: Apuesto a que si te discuto, pasarás del "código linux" (gnu-linux, el SO completo, a decir "si, bueno, gnu-linux está afectado pero el kernel linux no"), reduciendo cada vez más. El tema es que tu ordenador es lo que es, desde el kernel linux hasta el último tornillo de tu teclado y a la NSA le da igual donde tengas la puerta trasera con tal de que la tengas, así que no te reduzcas al kernel.

Pero aún reduciéndonos sólo al kernel linux, sigues teniendo mucha fe en él.

P.D: ¿acaso te crees que AMD se libra?

[#116 Nathaniel.Maris]

#83 ¡Que me hackeen el router que tengo montado en Lin....... ohh wait!.

[#173 Desactivado]

#26 En cuanto OpenBSD tenga soporte KMS (está en la current) me paso, lo tengo dicho.

Total,tengo todos los programas de SL de Linux y compatiblidad binaria con éste.

#83 Linux-libre.

[#6 Desactivado]

#4 Tu eres muy optimista, me parece.

[#16 vickop]

#6 y tú muy pesimista, me parece.

[#18 Desactivado]

#16 Mas bien realista. No me negarás que Stallman tenia parte de razon en sus argumentos ...

[#21 vickop]

#18 No te lo he negado. Tan solo te he hecho el comentario para recalcarte que se necesita un poco más de argumentación para hacer la afirmación que haces.

[#77 Desactivado]

#18 Stallman siempre ha tenido razón en sus planteamientos. Otra cosa son las conclusiones a las que llega, como por ejemplo negarse a tener móvil.
Yo ya sé que si tengo móvil la policía y los servicios secretos pueden saber dónde estoy aunque lo tenga apagado y, evidentemente, también pueden saber qué estoy enviando/recibiendo aunque encripte la comunicación. Pero eso no me impide tener móvil, aunque procuro usarlo con precaución. Es cuestión de prioridades y también de intentar que esto en el futuro no continúe así pero sabiendo que ahora mismo es lo que hay.

[#96 DiCrEn]

#77 Si Stallman pensasé de esa forma, diciendo "esto es lo que hay" no le tomaríamos nada en cuenta. A mi me parece perfecta la actitud de Stallman siendo quien es.

[#115 Desactivado]

#18 Stallman siempre ha sido un genio, y como tal, ridiculizado por muchísima gente, incluso amantes de la informática, cosa que no entiendo. Yo, como amante de la informática he tenido épocas en las que también creía que exageraba, pero ni de coña me habría mofado de el jamás. De hecho uno de los mayores honores que he tenido en mi vida en mi opinión ha sido entrevistarle telefónicamente para el blog donde escribía.

[#24 Desactivado]

#4 El pequeño problema es que la duda está en un blob cerrado que puso Intel, con lo que no se puede leer el código.

[#26 Desactivado]

#4 És exactamente de lo que se quejó en su dia Matt Mackall a Linus, que no se podia auditar el código.

http://comments.gmane.org/gmane.comp.security.cryptography.randombit/4689

Y por la manera en la que tienen de explicarlo en LinuxMagazine, no es que "pueda", es que todo el que haya instalado el parche de RdRand a partir de cierta versión, tiene la puerta trasera.

En la pagina del paquete de la Wikipedia hay algo mas de información al respecto:

http://en.wikipedia.org/wiki/RdRand

[#29 Jakeukalane]

#26 El puede también se refiere a que no se han puesto de acuerdo en sí es una puerta trasera operativa o no, funcionamiento etc.

[#39 Desactivado]

#29 cierto también

[#49 jsianes]

#4 si el parche introducido no es opensource no puede aditarse de ninguna forma. Lo bueno es que sí podría cambiarse, y viendo las claras sospechas que hay al respecto sería lo mas adecuado para asegurar la seguridad de los sistemas en entornos con información sensible.

[#69 Desactivado]

#4 El problema es que la generación de números aleatórios de Intel no es código si no un chip que los genera, y por tanto no se puede auditar como lo hace.

Pero esto es como la BIOS de los ordenadores. Tu puedes tener un SO de código abierto, pero si la BIOS de tu ordenador no lo és no puedes estar seguro que no haya una puerta trasera allí.

Supongo que por eso Linus admitió el cambio, porqué si no, por la misma razón, no podría usarse nada del software empotrado en los chips del própio ordenador.

[#113 Desactivado]

#69 Añado.

Sin embargo el caso de los números aleatorios es más pernicioso ya que (presuntamente) afecta a la generación de claves de encriptación y por tanto podría permitir acceder a información encriptada, algo que no es posible solo con conseguir el control de un ordenador ya que además necesitarias la clave de encriptación.

[#104 Desactivado]

#4 Aunque ya te han contestado, hay que tener muy claro que el código abierto no garantiza nada, ya que es un mantra muy extendido. Eso sí, el código abierto te permite auditarlo, y no se puede negar que eso sea una ventaja.

Sin embargo tampoco hay que olvidar lo que sucede en otros ámbitos en los que mientras más observadores hay, hay menos personas que actúan porque esperan que lo haga otro. Aunque no es del todo aplicable a este caso, excepto quizás en el sentido de que a nadie le ha importado que se haga uso de una caja negra que nadie sabe que contiene, pero es que muchas veces hay código que nadie mira porque es infumable.

Alguna vez he intentado informar de algún fallo de alguna distribución en particular y muchas veces me encuentro que el bug ya ha sido reportado por lo general desde hace más de 5 años, y hay muchos reportes duplicados año tras año, y sin embargo nadie lo ha mirado: porque el código es infumable, porque corregirlo implica rescribirlo todo, porque no se sabe donde se produce el error, y cuando no se dan excussas, incluso al margen de que se reconozca el fallo se dan ataques: porque no lo haces de otra forma, usa otro programa, otro dispositivo, para que necesitas eso, etc.

Esto no es tanto una queja sobre ello, sino más bien para que tampoco seamos ingenuos, el que "cualquiera" pueda leerlo no implica que alguien lo haya leído, básicamente como los términos de uso de cualquier programa, y lo peor es que aún si alguien lo lee, eso no implica que sepa que demonios está leyendo.

[#154 Desactivado]

#4 En realidad es posible esconder troyanos incluso en un proyecto de software libre: http://cm.bell-labs.com/who/ken/trust.html

Como dice el artículo "You can't trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code."

[#1 Desactivado]

PUDO NO. Lo incluyó. Linus te han pillao !!!!

[#8 Jakeukalane]

#1 Edito el título. Anterior: Linux pudo haber incluido en su generador de números aleatorios una puerta trasera de la NSA [ENG]

[#9 Jakeukalane]

#1 ¿Cómo narices edito el título?

[#31 abuelillo]

A ver si me aclaro. Intel no es la misma que fabrica los procesadores ?
Alguien ha auditado el microcodigo/diseño de los procesadores intel para saber si tienen puertas traseras o no ?
Alguien audita el codigo de las BIOS ?
Alguien audita las propias placas base, discos duros, tarjetas de red ?
Si los fabricantes de hardware+gobierno quieren controlar los equipos a esos niveles podrían hacerlo y no hay mucho que se pueda hacer para evitarlo.

[#34 scalvo]

#31 Por lo que entiendo esto no es una cuestión de software sinó de hardware... El tipo que mantenía la las librerías de aleatoridad dimitió al permitir Linux una serie de llamadas a un hardware de Intel sospechoso que no es auditable.

[#42 abuelillo]

#34 Es que no es auditable ningun hardware. Si compras una placa base de un fabricante, tienes que confiar en que la placa base no tenga ninguna puerta trasera.
Si un determinado hardware trae un chip para generar numeros aleatorios reales, que son los mejores para el tema de criptografia, lo logico es que el software use chip.
Que se gana con que el software no use ese chip ? O es que vamos a confiar en que intel solo pondrá una puerta trasera en ese chip, y no en el resto de hardware que trae la placa base !!!
Si alguien cree que intel hace eso, y necesita una garantia absoluta de seguridad el unico camino posible os no usar ningun hardware fabricado por Intel.

[#47 Mancini]

#42 Es verdad; la paranoia es el estado superior de la realidad.

[#35 oxelo]

Vivimos en un mundo en el que todo lo que parecen conspiranoias se terminan confirmando... vaya mierda de mundo.

[#37 Desactivado]

Ya decía yo que en Chatroulette siempre me salía el mismo pajillero. Sería un pajillero de la NSA.

[#82 Desactivado]

Noooo Linuuuxxx!!! en qué van a creer ahora los meneantes pedantes??

[#162 Trigonometrico]

#82 Tú siempre has usado Windows y nunca te han preocupado estas cosas.

[#28 ElPerroDeLosCinco]

Esto me reafirma en mi preferencia hacia AMD frente a Intel. Aunque tampoco creo que sean santos.

En fin, que el que quiera números realmente aleatorios, que espere a la siguiente EPA (calzador mode off).

[#59 Cachisen]

A veces lo flipo un poco. A lo mejor estoy muy perdido, pero alguien se ha leido la noticia?

Porque yo no veo NSA por ningún lado. Que hay codigo cerrado, puede. Que hay un generador aleatorio de Intel que es "inauditable", también. Pero de esto al titular hay un trecho, no?

[#46 rakinmez]

HAce 15 años, me llamaban loco
hace 15 años, era un bicho raro
hace 15 años, decia que nos manipulan

han pasado 15 años!!!!!, y el tiempo me ha dado la razon

[#61 ombresaco]

#46 Nos manipulan*, pero sigues siendo un bicho raro, y un loco

*Por el contexto de la noticia sería espían (la manipulación se lleva haciendo desde siempre)

[#68 hamster_ruso]

Sólo hay una forma de ver si ha habido tongo: Ponemos a todos los ingenieros de Intel en el centro de un descampado y dividimos el área del descampado en una cuadrícula de 500x500 celdas. Haciendo uso de la función rand de Linux metemos una mina en la mitad de celdas. Si no sobreviven es que no hay tongo. Si sobreviven, pues cojamos las horcas y les perseguimos para mostrar nuestro malestar.

[#41 angelitoMagno]

¿Y ahora que hacemos? ¿Usar HURD?

[#53 Moléculo]

#41 ¿Para seguridad? nah, OpenBSD

[#65 amstrad]

#53 Ni OpenBSD se salva

http://cryptome.org/2012/01/0032.htm

[#72 Moléculo]

#65 Joer...

Plan 9?

[#175 Desactivado]

#72 Tranquilo, sigues seguro con OpenBSD, se demostró que no hay troyano alguno. Theo de Raadt tiene los cojones de acero, y su OS es usado en corporaciones americanas con seguridad extrema.

No van a tener cojones los de la NSA a atacar al creador, antes quita el soporte a tales corporaciones y se arma un caos en la bolsa que riéte del crack del 29.

[#73 Jakeukalane]

#48 Pero digamos que pasen cosas de estas en el kernel Linux o en FreeBSD OpenBSD [ #65 ] (como la última que hubo que fue algo parecido pero con OpenBSD) es más extraño que que pase en otros porque se valora más la seguridad que en Mac o en Hahahahawindows.

Eso es lo grave del asunto (que está por confirmar).

[#174 Desactivado]

#65 Se ha demostrado que la introducción del troyano en OpenBSD fué mentira. Por favor, no manipules.

Además, OpenBSD es canadiense. Nada de NSA o rollos de exportación de cifrados.

[#19 Desactivado]

Al final voy a tener que seguir los consejos de Stallman.

[#54 skgsergio]

#19 No usar el ordenador? Navegar usando un sistema automatizado que trae las webs por email? Usar Debian con núcleo Hurd y solo repo free?

[#159 f2105]

#19 Pues no te veo con un gorro hecho de paneles solares en vez de papel de aluminio.

[#48 hamster_ruso]

El caso es que la supuesta intrusión se debería a que el núcleo emplearía un comando de hardware para calcular los números aleatorios en vez de elaborar su propia rutina. Es decir, esto afectaría a cualquier sistema operativo que utilice instrucciones de hardware para realizar esta tarea en vez de emplear su propia solución software... Y bueno, a día de hoy mayoritareamente desde Windows hasta Mac se emplea hardware de Intel. Vamos, que Linux no es el único que previsiblemente se va a llevar las manos a la cabeza, más de uno debería de ir pidiendo una guillotina en la sede de Intel.

[#58 llou]

Titular incorrecto, lo que hizo Linus es dar de paso el acceso directo a la función aleatoria del hardware y sería esta la que podría estar comprometida por la NSA. Y esto era en la era pre-Snowden mucho menos paranoica, ahora sería muy recomendable que esta funcion fuera una opción de compilación del Kernel.

De todas formas quien quiera seguridad de verdad existen generadores de números aleatorios por hardware.

[#80 Desactivado]

Alguien se acuerda cuando Intel saco el pentium3 que venia con un ID unico que se podia leer desde internet ? si hablamos del año 99 creo ? jajajjajajjaj Welcome to NSA! ahora todos los que usemos INTEL, estamos seguros ?
http://es.comp.hardware.misc.narkive.com/wts6oJza/identificador-unico
El mundo es ingenuo!!

[#85 bensidheseleccion]

Pues por esa puerta trasera se me han debido de colar las 3000 peliculas, 45 series y 8000 discos que tengo, que cabrones.

[#2 Desactivado]

Hay slgo no edpiado por EE.UU?

[#246 Desactivado]

#245 Eso lo tenemos de serie de hardened gentoo, el objetivo en seguridad es tener 20000 capas de seguridad, y tenemos compilados de forma segura por defecto los binarios (mírate las SPECS de hardened gentoo), además tenemos PaX y MAC

Sería útil ver algo así como PaXtest en openbsd para comparar vuestras salidas.


USERLAND: gcc specs: fstackprotector-all -D_FORTIFY_SOURCE=2 -PIE
KERNELLAND: PaX+RSBAC


* System-wide ASLR: PaX ASLR enabled

* Does the CPU support NX: Yes

COMMAND PID RELRO STACK CANARY NX/PaX PIE
init 1 Full RELRO Canary found PaX enabled PIE enabled
cron 1768 Full RELRO Canary found PaX enabled PIE enabled
clamd 1922 Full RELRO Canary found PaX enabled PIE enabled
freshclam 1929 Full RELRO Canary found PaX enabled PIE enabled
gkrellmd 1941 Full RELRO Canary found PaX enabled PIE enabled
syslog-ng 1963 Full RELRO Canary found PaX enabled PIE enabled
syslog-ng 1964 Full RELRO Canary found PaX enabled PIE enabled
sshd 1979 Full RELRO Canary found PaX enabled PIE enabled
rklogd 2004 Full RELRO Canary found PaX enabled PIE enabled
hiawatha 2009 Full RELRO Canary found PaX enabled PIE enabled
login 2016 Full RELRO Canary found PaX enabled PIE enabled
agetty 2017 Full RELRO Canary found PaX enabled PIE enabled
agetty 2018 Full RELRO Canary found PaX enabled PIE enabled
agetty 2019 Full RELRO Canary found PaX enabled PIE enabled
agetty 2020 Full RELRO Canary found PaX enabled PIE enabled
agetty 2021 Full RELRO Canary found PaX enabled PIE enabled
fbterm 2030 Full RELRO Canary found PaX enabled PIE enabled
bash 2043 Full RELRO Canary found PaX enabled PIE enabled



PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux orion 3.10.7-rsbac #2 Sun Sep 1 21:10:00 CEST 2013 i686 QEMU Virtual CPU version 1.0 GenuineIntel GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable stack (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments : Killed
Anonymous mapping randomisation test : 18 bits (guessed)
Heap randomisation test (ET_EXEC) : 22 bits (guessed)
Heap randomisation test (PIE) : 26 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 16 bits (guessed)
Shared library randomisation test : 18 bits (guessed)
Stack randomisation test (SEGMEXEC) : 24 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (strcpy, PIE) : Vulnerable
Return to function (memcpy, PIE) : Vulnerable

[#25 Desactivado]

Tampoco podemos saber si hay instrucciones ocultas en la CPU, puestos a ser conspiranoicos debemos construir nuestro propio hardware, o podemos usar tarjetas especificas para ello, pero también nos deberemos fiar de un fabricante.

[#52 avat_light]

Vamos a ver. Si lo que hace este software no modificable es crear un número aleatorio. Lo que la NSA sabe es el patrón con el que se genera.
Pero aún así, aunque sepas el patrón.
¿Como sabes en que parte del ciclo del procesador se crea el número aleatorio?

Porque todos sabemos que en informática realmente no existe la aleatoriedad. No es como tirar un dado al aire. Solamente son ciclos de un procesador que se repiten, pero son ciclos tan largos que parecen números aleatorios. Así que lo que tendría que hacer el software es darles algún tipo de índice para saber en que ciclo del procesador esta cuando se produce el número aleatorio, no?
No soy un experto en esto, igual me estoy equivocando. Las preguntas son para alguien experto en procesadores.

¿Como puede la NSA utilizar esa información a su favor?

¿Quizás para encontrar contraseñas creadas aleatoriamente?

[#63 jmenendez]

#52 Seguramente no lo sepan a ciencia cierta, pero si sabes cómo se generan los números, puedes reducir enormemente el tiempo que te llevaría hacer un ataque por fuerza bruta.

[#67 Cachisen]

#63 si fuera por software de código abierto también sabrías cómo se generan los números. La cuestion es que no se puede saber cómo se genera ni si admite "algo más" que la obtención de un aleatorio.

[#140 sidez]

#52 La clave está en que al no poder auditar el hardware, tampoco puedes estar seguro de que realmente se generen números aleatorios y aunque así fuera, podrian estar generandose dentro de un espacio muy acotado, en este caso sería perfectamente posible tener un espacio de números aleatorios pero mucho más acotado de lo normal, lo que como comenta #63 reduciría el tiempo necesario en cualquier ataque por fuerza bruta ya que solo sería necesario probar los números que se encuentren dentro de ese espacio acotado.
Si se genera por software puedes evitar este problema, siempre que el resultado de las instrucciones que utilices en el generador sea conocido y predecible.

[#76 festuc]

#52 Si conoces el patrón de generación, no tienes más que esperar a que el pavo que quieras espiar envie algun paquete encriptado a alguien, y simplemente atacar ese paquete.
El pavo no sabrá que lo has interceptado, y no tiene manera de hacerlo.
Otra cosa seria el disco duro, la placa madre...
Si estos nos espiasen tendriamos trazas en los cables electricos de más. Como pasa con el windows que envia información no solicitada...

[#62 Shilfein]

¿O sea que Linux INCLUYE un hardware de Intel que incorpora una puerta trasera?
¿No será que se limita a USARLO? ¿Y cómo cojones iban a saber que algo que no han fabricado ellos tiene puertas traseras?

[#90 kolme]

En realidad lo que pasó es que Linux utiliza un generador de entropía por hardware si está disponible, y este puede estar comprometido. El parche "maldito" hace que no siempre se use el generador en software, que es más lento y en teoría menos "entrópico".

En realidad Linus estaba siendo pragmático (en su línea), ni mucho menos se ha vendido a la NSA.

[#81 Desactivado]

Quiero poner en orden mis propias ideas y de paso lo mismo tambien consigo poner en orden otras ideas. Supongo, que uno de los verdaderos problemas con una puerta trasera en la generación de los numeros aleatorios es la amenaza para nuestras comunicaciones seguras(ejemplo ssh). Generar un numero aleatorio es tan simple como captar el tiempo en un determinado momento. Ahora bien, despues de esta primera aclaración, supongo que el hardware de Intel no genera sencillos numero aleatorios, sino numero primos que nos sirven para la seguridad en nuestras comunicaciones. Entoces la pregunta que nos tenemos que hacer es: ¿Cuales son las causas para que podamos determinar los numeros concretos que nos dara una función que esta implementada en el Harware de Intel?

[#51 jmenendez]

Yo no veo tan grave que linux tenga soporte para generadores de números aleatorios por hardware, siempre y cuando no sea la única fuente y se pueda desconectar o venga desconectado por defecto.

[#78 angelitoMagno]

O estoy muy despistado, ¿o donde dice la noticia original algo sobre la NSA o sobre backdoors?

[#74 sacaelwhisky]

Linux SuSe (Sociedad unitaria de Sólo espías).

[#32 gilipipas]

Joder, y eso que sólo estamos viendo la puntita del iceberg.

[#56 HaScHi]

Con lo fácil que era lo de ir cogiendo papelitos al azar de una caja para sacar los números aleatorios...

[#45 gobo]

Si lo entiendo bien, el problema es como se ha dicho por arriba que se usa una instrucción hardware para generar números aleatorios dicha función integrada en el micro no puede ser evaluada y se sospecha que puede ser usada como punto de entrada para una puerta trasera, aunque sea simplemente porque al eliminar la "aleatoriedad" se puede simplificar enormemente el acceder a la información de un equipo cifrada o no.


Realmente es un tema preocupante y está claro que puestos a colocar puertas traseras tiene mucho más sentido hacerlo a nivel de hardware que de software.

[#100 Mariele]

Erre que erre con la obsesión de comerse la intimidad de las personas. Me pregunto en qué se supone que favorece al ciudadano que su gobierno sea capaz de enterarse de todo. Casi lo entendería si por ejemplo te robaran el móvil o el portátil y en 24 horas la policia te lo devolviera, pero no es ni será el caso. Todo ese potencial se gasta en neutralizar a aquellos que son verdaderamente críticos con el sistema y hacen algo serio para cambiarlo, léase Assanges y compañía.

[#89 Desactivado]

La generación de números aleatorios es un problema más complicado de lo que parece. En cualquier caso Linux y cualquier otro sistema debería implementar su propio sistema por software de forma independiente del hardware, aunque ello genere una pequeña latencia en el sistema cuando se utilice esa función.

[#94 avat_light]

#89 Ya te digo. Es un tema extremadamente complicado. incluso en la realidad es difícil crear un número aleatorio en un entorno controlado.

[#286 Desactivado]

#89 La generacion de numeros aleatorios es un problema de la funcion rand y similares, asi que es un problema de compiladores y de como la implementen, no de sistemas operativos. aunque linux no usase esa instrucción podría usarla por ejemplo firefox si a sus programadores les diese por pasar de las librerias de linux y hacer las suyas propias por soft usando esa instrucción.
Ademas de que todos los lenguajes ya tienen esas instruciones generadoras de numeros aleatorios por soft ya que hasta ahora siempre se ha hecho asi y hay directivas de compilación para no usar esa instruccion y hacerlo por soft ya que esa instrucción no la soporta amd ni muchos procesadores intel relativamente nuevos.

[#43 Milkhouse]

Nos espían por nuestro bien..... Corruptilandia, todo el sistema es asín

[#98 dotromas]

La diferencia entre Linux y otros sistemas cerrados, es que ahora se sabe donde esta el problema en concreto y tienes la opción de usar generadores por software o quitar ese parche si alguien lo instalo. Además a raiz de esto te saldrán 200 generadores por software que mejoren su rendimiento por software (aunque no iguale a uno por hardware).

Si tienes un sistema cerrado no te vas a enterar de nada y por supuesto no vas a ver nada ni poder desactivar o parchear nada como a ti te guste. Esa es la diferencia.

Linux es muchisimo mas seguro que los sistemas cerrados porque al menos tienes la posibilidad de descubrir y arreglar ese tipo de problemas (cosa que en un sistema cerrado es imposible y nunca podrás hacerlo). Lo siento pero no hay comparación posible. Por supuesto cuando se use Linux, se debe evitar todo software cerrado o sin codigo disponible como recomienda Stallman.

[#101 Marx]

#98 No es por nada pero el chip de marras es cerrado.

Por otro lado, nos hemos dado cuenta de un problema, de uno por el cuál una persona dimitió, así que no parecía tan difícil de predecir. ¿cuántos más existen? ¿puedes arreglar lo que no conoces?

[#92 Marco_Pagot]

Ya lo decía Rosario Flores: Uy uy uy uy mi pingüino hace uy uy uy uy uy ♪

[#27 tommyx]

a ver, fue o no fue. Cual es la noticia ? Una noticia condicional ?

[#88 avat_light]

Vamos a ver . Vamos a poner un caso practico. Yo hago una conexión SSL. Mi ordenador para conectarse con un determinado servidor de forma segura. Le pide el certificado SSL. El servidor me envía la clave SSL.Mi ordenador genera una clave simétrica a partir del cifrado y codifica toda la información que envío y recibo . Pero aunque la NSA supiera el patrón con el que se ha generado esa clave simétrica.
¿De que le sirve?
Es decir,¿Como sabe el ciclo exacto del procesador donde se genero ese número aleatorio usado para elegir algún carácter de la clave publica?

Para ello mi ordenador tendría que enviarle esa información por red a la NSA. Si así fuera, el software de red debería ser capaz de detectar que un paquete se dirige hacia una IP desconocida o rara. No?

[#97 alephespoco]

#88 Te lo explico, y explico de paso cuál es el verdadero impacto de las vulnerabilidades de los generadores de números aleatorios en las comunicaciones seguras.

Tu ordenador para conectarse por SSL realiza la negociación de SSL donde se intercambian las claves públicas de las dos partes.
Simplificando, lo que se envía de una parte de la comunicación a la otra se cifra con la clave pública de la otra, que únicamente se puede descifrar con su correspondiente clave privada.

Donde importa de verdad los problemas en los generadores, es en que para generar las claves privadas, se utiliza un generador de números aleatorios, si este generador de números aleatorios está "cojo", en lugar de las 2^64 o 2^128 o 2^256 claves privadas posibles (dependiendo de la longitud de la clave), imagínate, que "sólo" se generan 2^12 claves posibles (por decir algo), de manera que en un tiempo computable se puedan comprobar todas las claves contra una conexión cifrada interceptada, pudiendo descifrarla.

Vamos, algo parecido a lo que pasó con el bug de openssl en Debian, pero mucho mas sibilino:
Explicación del bug OpenSSL en derivadas de Debian GNU/Linux

Explicación del bug OpenSSL en derivadas de Debian...

[#109 avat_light]

#97 Ok. Eso si tiene sentido. Thanks.

[#55 Desactivado]

Software libre: Limpio y seguro

[#134 Desactivado]

#55 Pues sí, el Software Libre es limpio y seguro frente al propietario, de hecho este agujero es resultado de incluir en el kernel binarios cerrados de una empresa. La solución es simple: mandar a la mierda al gordo de Linus, hacer más caso a Stallman y utilizar kernels 100% libres, que los hay:
https://es.wikipedia.org/wiki/Linux-libre

[#99 Desactivado]

Zas!! en toda la boca, que no nos libramos nadie, queridos linuxeros

Lo increíble es que una noticia "mala" sobre Linux llegue a portada, cuando lo normal es despotricar contra los de Redmond.

[#107 Desactivado]

#99 No te has enterado de nada, vuelve a tu windows y no te metas en conversaciones de mayores.

[#122 Nathaniel.Maris]

#99 La diferencia es que al usar Windows tenemos la certeza de que estamos jodidos, mientras que usando Linux tienes la duda de estar jodido o no. Yo prefiero lo segundo en todo caso. ¿O te crees que en Windows llegaría a darse el caso de que alguien dudara del sistema?, No puedes dudar de un sistema completamente opaco, solo puedes "tener fe" en lo que compras.