Portada
mis comunidades
otras secciones
#5:
#3 Y tanto que es factible. Sucede como con los virus, que todo el mundo asume que teniendo un antivirus se es inmune, cuando eso está a años luz de ser cierto.
En el caso del código abierto, todo el mundo asume siempre que los demás se encargan de vigilarlo o que hay alguien auditando el código continuamente, cuando prácticamente nunca es cierto. Lo que hay es simplemente una fe ciega en los responsables del proyecto.
Y en este caso los responsables del proyecto aceptaron un soborno para incluir puertas traseras en su sistema. Casi nada. Con ello comprometieron la seguridad de todos los proyectos derivados y de los innumerables usos que se le han dado durante diez años. Y porque se ha destapado el pastel, que si no...
Microsoft se debe estar frotando las manos, porque ciertamente este hecho hace desconfiar del código abierto y con motivo. Con esto tienen FUD para dar y vender.
#1 ¿Qué tal si te lees el artículo en lugar de desinformar a la gente? Los que pone son ejemplos de puertas traseras detectadas en el pasado. Las puertas traseras de las que habla Theo de Raadt aún han de ser encontradas, por ello pide ayuda para auditar el código.
En el caso del código abierto, todo el mundo asume siempre que los demás se encargan de vigilarlo o que hay alguien auditando el código continuamente, cuando prácticamente nunca es cierto. Lo que hay es simplemente una fe ciega en los responsables del proyecto.
Y en este caso los responsables del proyecto aceptaron un soborno para incluir puertas traseras en su sistema. Casi nada. Con ello comprometieron la seguridad de todos los proyectos derivados y de los innumerables usos que se le han dado durante diez años. Y porque se ha destapado el pastel, que si no...
Microsoft se debe estar frotando las manos, porque ciertamente este hecho hace desconfiar del código abierto y con motivo. Con esto tienen FUD para dar y vender.
#1 ¿Qué tal si te lees el artículo en lugar de desinformar a la gente? Los que pone son ejemplos de puertas traseras detectadas en el pasado. Las puertas traseras de las que habla Theo de Raadt aún han de ser encontradas, por ello pide ayuda para auditar el código.
#11:
#5 Un problema de seguridad en un proyecto, mediante soborno... ¡Oh! No parece que eso haga desconfiar del código abierto. El problema es el sobornado. Y al contrario, un problema de seguridad en software privativo, no es imposible pero ES mucho más difícil de detectar. En el opensource al menos puedes auditar el código. Y es que cabrones los hay en todos los lados...
#23:
Esto da una idea de cómo funcionan los que trabajan en Inteligencia. Lo que apunta el autor del correo a Theo de Raadt (que no sé si se ha leído la mayoría de los que están diciendo tontunas aquí y a los que parece darles igual lo que les señales porque el dedo es muy gracioso) es bastante inquietante:
- la financiación de DARPA que OpenBSD perdió quizás no fue porque Theo de Raadt renegó de las guerras organizadas para robar petróleo ( http://es.wikipedia.org/wiki/Theo_de_Raadt#Oposici.C3.B3n_a_la_guerra_de_Iraq ) , sino porque los de DARPA sabían que el IPSec de OpenBSD no era trigo limpio y no querían utilizar material no fiable.
- algunas de las lumbreras de las publicaciones sobre seguridad (muchas de las cuales recomiendan usar OpenBSD para todos los trabajos serios de seguridad) están directamente en la nómina del FBI, que es quien soltó la tela para que estos desarrolladores hicieran una puerta trasera en IPSec.
Los desarrolladores de OpenBSD siempre han sido muy pocos (ahora mismo deben estar sacando adelante el sistema operativo completo -y unas cuantas cosas más como OpenSSH nada menos- entre cerca de 50 personas), pero desde luego que son de lo mejorcito que hay en el mundo del software libre. Esto es un palazo para ellos, a ver cómo lo encajan.
- la financiación de DARPA que OpenBSD perdió quizás no fue porque Theo de Raadt renegó de las guerras organizadas para robar petróleo ( http://es.wikipedia.org/wiki/Theo_de_Raadt#Oposici.C3.B3n_a_la_guerra_de_Iraq ) , sino porque los de DARPA sabían que el IPSec de OpenBSD no era trigo limpio y no querían utilizar material no fiable.
- algunas de las lumbreras de las publicaciones sobre seguridad (muchas de las cuales recomiendan usar OpenBSD para todos los trabajos serios de seguridad) están directamente en la nómina del FBI, que es quien soltó la tela para que estos desarrolladores hicieran una puerta trasera en IPSec.
Los desarrolladores de OpenBSD siempre han sido muy pocos (ahora mismo deben estar sacando adelante el sistema operativo completo -y unas cuantas cosas más como OpenSSH nada menos- entre cerca de 50 personas), pero desde luego que son de lo mejorcito que hay en el mundo del software libre. Esto es un palazo para ellos, a ver cómo lo encajan.
#47:
Pues anque parezca paradójico, esto me hace confiar aún más en el código abierto. ¿Por qué?
Los desarrolladores presuntamente troyanizaron el código a petición del gobierno de EEUU. Vale, eso es grave. Pero queda la opción de revisar el código y corregirlo.
Ahora pensad un poquito: si el gobierno de EEUU presionó a los desarrolladores de OpenBSD, ¿cuál es la probabilidad de que hicieran lo mismo con los de desarrolladores del Windows?
¿Y cuál es la probabilidad de que Microsoft aceptara?
¿Y cómo vamos a comprobar si eso ha ocurrido o no, sin acceso al código del Windows?
No me respondan ahora, sino después de la publicidad.
Los desarrolladores presuntamente troyanizaron el código a petición del gobierno de EEUU. Vale, eso es grave. Pero queda la opción de revisar el código y corregirlo.
Ahora pensad un poquito: si el gobierno de EEUU presionó a los desarrolladores de OpenBSD, ¿cuál es la probabilidad de que hicieran lo mismo con los de desarrolladores del Windows?
¿Y cuál es la probabilidad de que Microsoft aceptara?
¿Y cómo vamos a comprobar si eso ha ocurrido o no, sin acceso al código del Windows?
No me respondan ahora, sino después de la publicidad.
#6:
#5, "Microsoft se debe estar frotando las manos, porque ciertamente este hecho hace desconfiar del código abierto y con motivo. Con esto tienen FUD para dar y vender."
Hombre, pues si da q pensar sobre el código abierto, no te creas q el código cerrado sale mejor parado... Más q nada xq directamente puedes no enterarte nunca si la empresa no quiere (y todos sabemos q hay maneras de saberlo, pero vamos a obviarlas).
Hombre, pues si da q pensar sobre el código abierto, no te creas q el código cerrado sale mejor parado... Más q nada xq directamente puedes no enterarte nunca si la empresa no quiere (y todos sabemos q hay maneras de saberlo, pero vamos a obviarlas).
#4:
#2 #3 Bugs con muchos años sin descubrir son posibles
Encuentran un bug en BSD 4.2 con 25 añitos de edad
Además parece que fueron los propios desarrolladores los autores.
Encuentran un bug en BSD 4.2 con 25 añitos de edad
Además parece que fueron los propios desarrolladores los autores.
Comentarios
#8 "Talk is cheap, show me the code"... Linus
Esto da una idea de cómo funcionan los que trabajan en Inteligencia. Lo que apunta el autor del correo a Theo de Raadt (que no sé si se ha leído la mayoría de los que están diciendo tontunas aquí y a los que parece darles igual lo que les señales porque el dedo es muy gracioso) es bastante inquietante:
- la financiación de DARPA que OpenBSD perdió quizás no fue porque Theo de Raadt renegó de las guerras organizadas para robar petróleo ( http://es.wikipedia.org/wiki/Theo_de_Raadt#Oposici.C3.B3n_a_la_guerra_de_Iraq ) , sino porque los de DARPA sabían que el IPSec de OpenBSD no era trigo limpio y no querían utilizar material no fiable.
- algunas de las lumbreras de las publicaciones sobre seguridad (muchas de las cuales recomiendan usar OpenBSD para todos los trabajos serios de seguridad) están directamente en la nómina del FBI, que es quien soltó la tela para que estos desarrolladores hicieran una puerta trasera en IPSec.
Los desarrolladores de OpenBSD siempre han sido muy pocos (ahora mismo deben estar sacando adelante el sistema operativo completo -y unas cuantas cosas más como OpenSSH nada menos- entre cerca de 50 personas), pero desde luego que son de lo mejorcito que hay en el mundo del software libre. Esto es un palazo para ellos, a ver cómo lo encajan.
#3 Que todo el mundo pueda leer las instrucciones no significa que tenga la disposición y la capacidad de interpretarlas y de situarlas en un contexto de software malicioso.
Se trataría de un troyano tan discreto que ni aún viendo superficialmente el código fuente te resultaría fácil reconocerlo. Hay ejemplos de ello en los snippets de código que anexa el meneo.
Me flipa esto. Es otro nivel. Un troyano furtivo hasta en su codificación.
Pues anque parezca paradójico, esto me hace confiar aún más en el código abierto. ¿Por qué?
Los desarrolladores presuntamente troyanizaron el código a petición del gobierno de EEUU. Vale, eso es grave. Pero queda la opción de revisar el código y corregirlo.
Ahora pensad un poquito: si el gobierno de EEUU presionó a los desarrolladores de OpenBSD, ¿cuál es la probabilidad de que hicieran lo mismo con los de desarrolladores del Windows?
¿Y cuál es la probabilidad de que Microsoft aceptara?
¿Y cómo vamos a comprobar si eso ha ocurrido o no, sin acceso al código del Windows?
No me respondan ahora, sino después de la publicidad.
#47
Teoria correcta
Realidad: tanto Open bsd como windows tienen puerta trasera
Ventajas reales?
No es por restarle credibilidad, pero teniendo en cuenta los flames conspiranoicos que se marcan a veces en Full-Disclosure, no me creo nada de este tema hasta que no vea pruebas mas concluyentes.
#7 Exacto. Si alguien cree que hay algo malicioso, que lo busque y lo muestre.
En cualquier software sea abierto o cerrado se pueden meter puertas traseras. La principal diferencia es que las puertas traseras en codigo cerrado son mucho mas facil de camuflar y de encontrar que en el codigo abierto.
Los casos de software libre con puertas traseras son minimos mientras que en programas privativos estan a la orden del dia.
Cada vez que un desarrollador manda nuevo codigo al repositorio se muestra publicamente por lo que otros desarrolladores del proyecto pueden ver los cambios y sugerir correcciones. De hecho generalmente suelen haber discusiones sobre los mismos en la lista de desarrollo. Luego estan los propios usuarios que pueden detectar comportamientos anomalos y revisar el codigo.
Esta noticia muestra el poder del software abierto, en un software cerrado "nunca" se habria descubierto.
#31 No os dais cuenta que esa es la teoria, pero que en la realidad, nadie lo hace.
Si EN TEORIA el software libre es superior al privado (y en muchos casos, lo es) pero que se pueda auditar el código no indica que se haga, el número de personas que pueden auditar el código de algo tan complejo como el ssh de openbsd se puede contar con los dedos, y seguro que tienen cosas mejores que hacer.
#3 me encanta leer a fanboys como tu negando lo evidente.
Ya sabes más de software libre que Theo, llama a esa loca y tranquilizale con tus palabras, que ha perdido el norte.
La de Jeniffer Lopez probablemente.
Más inquietante me parece esta otra puerta trasera... "La Ley Sinde, por la puerta de atrás"... aún después de todo, la van a conseguir colar
"La Ley Sinde, por la puerta de atrás".....
enriquedans.comAlgo a tener en cuenta por todos los que comentais que siendo codigo libre es mas sencillo que nos demos cuenta... es cierto, pero tened en cuenta que hablamos de CRIPTOGRAFIA y de ataques laterales.
Segun el correo original, se trata de leaks de la clave mediante canales laterales. En mi opinion, si existe dicha backdoor se trata de algo relacionado con diferencias en el tiempo de ejecucion de las operaciones en funcion de la clave.
Este tipo de ataques son conocidos PUBLICAMENTE desde el 95, aunque no han empezado a hacerse 'famosos' hasta mas recientemente fuera de la comunidad criptografica y la gente trabajando en embedded security y en temas de smart cards y hardware seguro.
Si se trata de una backdoor de este estilo, sera bastante dificil de encontrar. No es tan sencillo de encontrar como un bug clasico, un overflow, off-by-one, user-pointer dereference o similares.
Habra que ver en que evoluciona todo esto... y por supuesto, que no se encuentre no significa que no este ahi.
Joder. Imaginate que estas en casa viendo un partido, y te entran dos policias "No se levante, venimos a ver un par de papeles que tiene usted por aquí... a ver... hmmmm... vale... como va el partido, bien? Ostia, Paco, mira las fotos de su mujer, está cañon, eh? Espera que me hago una copia... CLICK. Bueeeeno... pues por hoy ya estamos, eh? Hala, hasta la próxima".
JA! Seguro que Windows no tiene ninguna puerta trasera
#28 #29 Me remito a esta noticia. Una puerta trasera introducida por la NSA y nadie ha auditado esa parte en 9 años.
#30 Pero es toda una noticia. Precisamente por eso es bueno.
¿Que es algo de lo que preocuparse? Por supuesto. Pero yo repito, se sabe y se puede corregir. ¿Qué ocurriría si el código fuese cerrado? Pues que nos comíamos la puerta trasera con patatas.
En cuanto a seguridad es obvio que el software libre tiene ventaja sobre el privativo. No sé que hay que discutir.
#37 Es toda una noticia nueve años después, ¿acaso eso no es comérselo con patatas?, joder, nueve añazos.
Fijo que lo publican porque ya quedó obsoleta y ahora tienen otra mejor, a estas alturas me creo cualquier cosa.
#30, ¿dónde dice que haya un backdoor? Solamente se habla de que puede haberlo, y de que supuestamente hubo planes de introducir uno. Suponiendo que los planes fuesen ciertos y se intentase, todavía hay que demostrar que tuvieran éxito.
#30 Voy a cambiar la negrita de sitio:
Me remito a esta noticia. Una puerta trasera introducida por la NSA y nadie ha auditado esa parte en 9 años.
Que parte? en esta noticia se pide ayuda para auditar TODO el codigo a ver si hay algo... Lo cual no significa que haya nada...
#56 ¿Falacia? No doy por hecho nada. Mi razonamiento: el código abierto SI se puede auditar. El cerrado NO. Eso es cierto. ¿Qué no entiendes?
#57 No te empeñes en que no dijiste lo que dijiste, anda. Relee tu comentario #11, que todos sabemos leer y entender.
#58 Ya, ya... si tienes razón. No se suele auditar el código. Pero en #11 digo que el problema es el sobornado. Y que este problema en software privativo es más difícil de detectar ya que en el opensource al menos puedes auditar el código.
Quiero decir que falacia es una argumento aparentemente verdadero, pero falso. He releído mis frases y no existe falacia.
La gracia del código abierto es que cosas como estas pueden ser descubiertas y arregladas por cualquiera que mire el código.
#19: Ya, cualquiera.
#24 #27 Cualquiera con tiempo y ganas, el código está allí para quien quiera verlo.
#19 por eso el JEFE de proyecto pide voluntarios para examinar el código...
Mac tambien. Pero solo las conoce Jobs
#12 Yo estoy seguro que jobs tiene las fotos de vuestras parejas... y se toca
Yo la trasera que da al jardin tambien hacia bien de ruido, pero un poco de 3en1 y como nueva.
Tambien se acaba de descubrir una puerta trasera en los arrays de HP, hay un usuario que no sale en la tabla de usuarios y su contraseña no puede ser cambiada
http://www.securityweek.com/backdoor-vulnerability-discovered-hp-msa2000-storage-systems
¿Todos esos bugs están en la parte del código que calcula el cambio de moneda?
#21 Dime que no has confundido OpenBSD con OpenBank o BSCH ...
Para mí lo más interesante del enlace son los cachos de código mostrando distintas puertas traseras metidas en software libre.
Hay algunas realmente jodidas de ver.
Menudo nivel se gastan (tanto los que las introducen como los que las descubren).
editado y borrado
El problema viene cuando te pones a ver el código y parece que está escrito por extraterrestres, haber como coño encuentras el troyano.
Yo después de lo de wikileaks, de verdad ya me creo cualquier cosa... los que antes me parecían unos paranoícos hablando de la teoría de la conspiración, cada vez me parecen más acertados...
Me da que nos manejan... y visto lo visto, sean rojos o a azules, al final los hilos parecen moverlos los mismos...
claro, temen que se cuele en un leak y prefieren "curarse en salud" ...
De qué sirve que un software tenga el código abierto si...
1) El usuario del software no sabe nada de programar software, y por tanto no entiende un código fuente.
2) Nadie se ha puesto ni se va a poner a inspeccionar todo el código.
He aquí la prueba de que el software de código abierto puede ser igual de malicioso que el de código cerrado. Y un auténtico OWNED para todos los talibanes del software libre, que no paran de criminalizar a los desarrolladores de software de código cerrado, como si el hecho de tener el código cerrado ya implicara que el código es malicioso.
Que cada cual publique el código de su software si quiere o no, y punto.
#6,#11 Yo no he hecho ninguna comparación. Me he limitado a describir lo que se avecina, que es un considerable torrente de FUD empresarial basado en la falacia que podéis leer en #50 mismo.
Esto va a hacer mucho daño al código abierto. Y no por motivos técnicos, es evidente. Se va a usar la inseguridad del código abierto (que existe, estamos ante un ejemplo claro) para defender falazmente la seguridad del código cerrado.
Y #11, caes en la falacia de que el código abierto es seguro sólo porque se puede auditar. El problema es que todo el mundo supone que lo auditan los demás, de modo que en la práctica no lo audita nadie.
Obviamente el comentario anterior en #52 es respuesta a #51
Parece bastante grave. Y también parece que han tocado el código de Linux.
#1 En el email no dice nada de Linux, y en principio la implementación IPSEC de Linux es diferente de la de OpenBSD.
Eso si, en Linux hay cosas como SELinux que fueron contribuidas por la NSA. Pero a mi me parece difícil que haya backdoors en código libre sin que nadie se entere ni ningún cracker los encuentre y explote en público durante años. Como dice la contestación siguiente (http://marc.info/?l=openbsd-tech&m=129236730027908&w=2), bien podría ser falso.
#2 exacto, una puerta trasera en sotfware abierto como que no es factible
#2 #3 Bugs con muchos años sin descubrir son posibles
Encuentran un bug en BSD 4.2 con 25 añitos de edad
Encuentran un bug en BSD 4.2 con 25 añitos de edad
osnews.comAdemás parece que fueron los propios desarrolladores los autores.
#3 Y tanto que es factible. Sucede como con los virus, que todo el mundo asume que teniendo un antivirus se es inmune, cuando eso está a años luz de ser cierto.
En el caso del código abierto, todo el mundo asume siempre que los demás se encargan de vigilarlo o que hay alguien auditando el código continuamente, cuando prácticamente nunca es cierto. Lo que hay es simplemente una fe ciega en los responsables del proyecto.
Y en este caso los responsables del proyecto aceptaron un soborno para incluir puertas traseras en su sistema. Casi nada. Con ello comprometieron la seguridad de todos los proyectos derivados y de los innumerables usos que se le han dado durante diez años. Y porque se ha destapado el pastel, que si no...
Microsoft se debe estar frotando las manos, porque ciertamente este hecho hace desconfiar del código abierto y con motivo. Con esto tienen FUD para dar y vender.
#1 ¿Qué tal si te lees el artículo en lugar de desinformar a la gente? Los que pone son ejemplos de puertas traseras detectadas en el pasado. Las puertas traseras de las que habla Theo de Raadt aún han de ser encontradas, por ello pide ayuda para auditar el código.
#5, "Microsoft se debe estar frotando las manos, porque ciertamente este hecho hace desconfiar del código abierto y con motivo. Con esto tienen FUD para dar y vender."
Hombre, pues si da q pensar sobre el código abierto, no te creas q el código cerrado sale mejor parado... Más q nada xq directamente puedes no enterarte nunca si la empresa no quiere (y todos sabemos q hay maneras de saberlo, pero vamos a obviarlas).
#5 Un problema de seguridad en un proyecto, mediante soborno... ¡Oh! No parece que eso haga desconfiar del código abierto. El problema es el sobornado. Y al contrario, un problema de seguridad en software privativo, no es imposible pero ES mucho más difícil de detectar. En el opensource al menos puedes auditar el código. Y es que cabrones los hay en todos los lados...
#11 Demuestra que mi razonamiento es falaz. "Al menos en el opensource SI puedes auditar el código y en el privado NO". Te confundes, porque no dije que sea sencillo auditar un código, pero se puede hacer y se hace.
Lo del FUD de Microsoft es cierto, porque lo hace siempre.
#52 La falacia es que das por hecho que por ser auditable es auditado y por ello seguro. En la realidad prácticamente nunca es así.
#2 Pero a mi me parece difícil que haya backdoors en código libre sin que nadie se entere ni ningún cracker los encuentre y explote en público durante años
¿Y OpenBSD que es? Código libre. Totalmente de acuerdo con #5 La gente presupone que los programas de código libre son revisados por millones de ojos pero, ¿realmente es así?
#26 No, pero probablemente examines la parte del código que te interesa.
#26 es cierto que en muchos proyectos o no se audita o se audita "por encima". De todas formas las ventajas siguen patentes: Nos podemos dar cuenta y corregirlo.
Si no estuviese disponible el codigo a saber si nos dariamos cuenta.
#5 uf, que agresividad. Mis disculpas, es cierto. Son ejemplos de casos anteriores. Pero entonces encuentro el titular un tanto confuso.
#2, #3, si leéis el texto veréis todos los ejemplos puestos en código abierto (que son los más conocidos). Si es el propio autor de confianza quien incluye los backdoor la cosa es más difícil de detectar.
#2 Pues dime entonces que pasó con openssh en su tiempo
#2 Lo de Linux lo comento por lo que he podido leer en la noticia:
Linux kernel 2.6-test9-CVS, 6 de noviembre de 2003. Acceso al repositorio y modificación del código del kernel para introducir una puerta trasera y escalar a privilegios de root. Más detalle en la entrada que le dedicamos. CVE 2003-1161. El cambio fue realmente discreto:
[..]
#2 Lo mejor es este párrafo:
Of course in these days of binary only blob drivers, I don't think the
government need resort to this sort of tactic these days. Those nice
binary-only drivers everyone loves running for video and wireless will
ensure that there are nice places in your favorite Open Source project
that can be coopted quietly by government organizations and have
access to your entire kernel. No need to be subtle.
#40 Menos mal que hay distribuciones como Trisquel o gNewSense. Ahora solo falta que los drivers libres Nouveau den un rendimiento aceptable en 3D.