Blogalia

"En el arte marcial como en la vida diaria. En la vida diaria como en un arte marcial."

Aikido

Sígueme en Twitter

<Agosto 2017
Lu Ma Mi Ju Vi Sa Do
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      


Todas las Historias

VELOCIDAD DE ESCAPE

Inicio > Historias > CON HUMOR, LO TOMAMOS CON HUMOR

2008-05-19

CON HUMOR, LO TOMAMOS CON HUMOR

Ciertamente una de los principales argumentos que se sostenían para el apoyo a las plataformas de software abierto, era el hecho de que la seguridad, basada en varios factores, como la disponibilidad del código, la posibilidad de corregir por tí mismo los fallos, y la velocidad en la resolución de las vulnerabilidades, era mayor.

Día tras día se va viendo que esta tesis encaja más en la idea de un modo de hacer Marketing, en un modo de mostrar la diferenciación de mi producto frente al de los demás que ciertamente en la existencia de una seguridad mayor, que aparte de la protección debida a la nula ubicuidad de estos sistemas, poco más puede ofrecer.

Una de las más graves y recientes, que hace que desde el año 2006 las claves generadas con OpenSSL pueden ser reventadas en minutos debido a que alguien borró una línea de código, me confirma en la idea de que la famosa tesis de "cuantos mas ojos hay sobre el código, mejor", es cuando menos falsa, y en el peor de los casos, peligrosa.
Al menos en mi experiencia, cuando más gente mete la cuchara en un proyecto, peor. A partir de un numero determinado de personas, la cosa se desmadra, y como muy bien conocen los psicólogos sociales (caso Kitty Genovese), muchos ojos viendo un problema, hace que se diluya la responsabilidad y al final todo el mundo escurre el bulto esperando que lo resuelva otro, al margen de que la gestion de personas en proyectos grandes o de muchos implicados es un autentico sembrado de cagadas peligrosas.

Así que nos lo tomamos con humor.

Programación | jomaweb | 7 Comentarios | Enlace


Referencias (TrackBacks)

URL de trackback de esta historia http://jomaweb.blogalia.com//trackbacks/57481

Comentarios

1
De: Anónimo Fecha: 2008-05-19 17:14

Tu sesudo análisis se olvida de comparar este gambazo de Debian con gambazos similares en el modelo de código cerrado. Tomemos esta vulnerabilidad en el PRNG de Windows, que afecta a todas sus versiones anteriores a Vista.

La vulnerabilidad lleva aparentemente más de 10 años en el código base de Windows. ¡Uf!

Fue detectada en noviembre y el parche para Windows XP ha salido hace unos días. Eso son 7 meses. De Windows 2000 no se conoce parche. ¡Ouch!



2
De: Hector Fecha: 2008-05-19 23:47

si !!, windows tiene muchisimas vulnerabilidades, por que esas nunca las comentas ? aaah cierto, la onda es despotricar contra el open source...

Como sea es importante que este tipo de cosas se de a conocer, para que se corrijan.



3
De: Fernando Fecha: 2008-05-20 02:31

Como dice #1:
OpenSSH, dos años con agujero... tiempo de respuesta?

Windows, 10 años con agujero... tiempo de respuesta?

Pues eso, parcialidad, no esperes que te tomemos en serio cuando hablas de Software Libre porque tu no te lo tomas en serio... cuando Oracle, por poner alguien que nadie conoce, si que lo hace.



4
De: MShip Fecha: 2008-05-20 07:03

Sólo una pregunta: ¿se tiene conocimineto de algún "exploit" que se aproveche de la vulnerabilidad del PRNG de Windows? Anteriores a diciembre de 2007 me refiero, porque posteriores a esa fecha y conociendo el qué y el cómo me (y con 7 meses de gracia) imagino que habrá sido "más sencillo"...

...y a eso iba. Por lo que llevo leyendo, la dificultad de detectar dicha vulnerabilidad es cuando menos muy similar a la ya subsanada en Debian, lo cual me lleva a pensar que dados el escrutinio al que se someten los sistemas de Microsoft fuera de las instalaciones de la corporación Redmond y la "aparente" facilidad con la que se detectan los fallos de seguridad en sus productos digo yo que tardar 10 años en detectar este del PRNG debe ser todo un record a su favor, ;-) porque imagino que la dificultad debe ser la misma tanto para hackers como para crackers...

Desde luego que no me tranquiliza. Como tampoco me tranquiliza el caso de Debian.

Un saludo.



5
De: Heimy Fecha: 2008-05-21 14:07

Para variar, artículo que escribes como te sale la punta del nabo: "que hace que desde el año 2006 las claves generadas con OpenSSL [..]". A veces me pregunto si realmente lees los artículos, si los lees con un filtro mental, o qué cojones. Igual te pasó con lo de MySQL el otro día, que lo que soltaste tenía que ver aún menos con la realidad.

No, querido. Que hace que desde cierta versión concreta de OpenSSL publicada en el año 2006 por _Debian_ (y derivados) y nadie más. Y te informo de que el mundo mundial que usa OpenSSL no es sólo Debian, por si acaso no lo sabías. Y sí, algunos hemos tenido que sufrirlo e ir corriendo a cambiar claves (por suerte, sólo de un par de máquinas), porque algún imbécil tuvo un mal día.



6
De: Juan Lupión Fecha: 2008-05-21 18:47

@Heimy: Aquí detallan bien la historia. Parece ser que el desarrollador de Debian *preguntó* a los de OpenSSL y le respondieron que la linea, en efecto, se podía borrar. Lo cual apoya las inquietudes de Jomaweb sobre el modelo de desarrollo de software. Aquí hay un artículo escrito sin histerismo

http://research.swtch.com/2008/05/lessons-from-debianopenssl-fiasco.html




7
De: Anónimo Fecha: 2008-05-21 19:03

Esto es lo que dice Ben Laurie, desarrollador de OpenSSL, sobre ese famoso thread:

In this thread, the Debian maintainer states his intention to remove for debugging purposes a couple of lines that are “adding an unintialiased buffer to the pool”. In fact, the first line he quotes is the first one I described above, i.e. the only route to adding anything to the pool. Two OpenSSL developers responded, the first saying “use -DPURIFY” and the second saying “if it helps with debugging, I’m in favor of removing them”. Had they been inspired to check carefully what these lines of code actually were, rather than believing the description, then they would, indeed, have noticed the problem and said something, I am sure. But their response can hardly be taken as unconditional endorsement of the change.



Nombre
Correo-e
URL
Dirección IP: 54.156.92.46 (4f142c16b1)
Comentario