Bueno, bueno, bueno, es lunes, ¿que tal la vuelta al curro? Ya se empiezan a acabar las fiestas de los pueblos, y cada vez se pone en el horizonte más cerca la cuestita de Octubre, Noviembre y Diciembre. Uff, vaya Tourmalet!!
Aprovechando que Txipi se pasa ahora por este blog, vamos a volver hablar del tan traido caso de "publicar el código fuente hace que se detecten antes o más número o se arreglen antes los fallos de seguridad" que el hacía refencia en su blog.
Muchas veces me han dicho, joder, ¿cómo es que Microsoft, teniendo herramientas de análisis automático de código para hacer análisis estáticos y dinámicos sigue teniendo fallos?
La respuesta es que las herramientas de revisión de código tampoco son perfectas, y a pesar de la retroalimentación siempre se dan nuevas situaciones de código, nuevos patrones, nuevos entornos de ejecución que pueden resultar vulnerables. Ya hemos hablado varias veces de que un mismo código, puede ser o no vulnerable, dependiendo del linkador, el compilador, el entorno de ejecución, etc...
Así, después de ver los resultados del primer examen de Coverity sobre productos como Apache, el kernel u Open Office, vimos que los ojos no ven todos los fallos, y que son necesarias eses tipo de herramientas. Pues bien, a principios de este mes se volvió a repasar el código base de Firefox, con otra herramienta de análisis automático estático, Klocwork K7, y han vuelto a aparecer fallos, 655 defectos y 71 que pueden ser vulnerabilidades de seguridad. ¿Es que Coverity es mala herramienta que se dejó todos estos sin descubrir? La respuesta es que las herramientas van evolucionando y retroalimentandose de nuevos patrones y ojala llegaramos algún día al famoso bugfree que uno publicó tras los análisis de coverity.
En fin, lo curioso de todo esto es, que tras el análisis se ha decidido no dar información sobre los fallos por prudencia. Vaya, ¿no dar información sobre los fallos por prudencia?. Me quiere sonar esto a alguna otra compañía, pero no caigo ahora. Creo recordar, entre las nubes que dejan las drogas en mi mente, que a las compañías que han argumentado esto les ha acusado de "Seguridad por Oscurantismo". Qué difencia de palabras Prudencia y Oscurantismo.
En fin, todo cambia, hasta en Mozilla contratan personal de Seguridad de Microsoft.
Comentarios al respecto:
ResponderEliminar1) La posición de Mozilla con respecto a sus fallos me parece poco coherente con su política abierta. Está claro que no se puede hablar de oscurantismo en unos casos y prudencia en otros. El hecho es el mismo.
Mi opinión sobre este tema es que me parece correcto no avisar del fallo hasta que no se tenga una solución, aunque sea tan drástica como "desactiva ActiveX/Java/loquesea de tu navegador". Nunca he criticado al software privativo por no avisar de fallos que saben que tienen si todavía no tienen una solución preparada.
2) Estoy de acuerdo en que las herramientas de validación automática de código es "the way to go". Los supuestos miles de ojos que revisan código se quedan pistojos frente a las expresiones regulares y los motores de inferencia, más si son retroalimentados. Lo bueno de tener el código a la vista es que estas baterías de validación las puede hacer gente ajena al proyecto y reportarte los fallos. Es decir, el equipo de Firefox no tiene por qué tener a gente 100% dedicada a ello, puede pedir que se le ayude en este tema y muy probablemente haya voluntarios para hacerlo. Sí, también habrá voluntarios black-hat con ganas de marcha que quieran hacerlo para otros fines, pero la posibilidad de ambos lados de la fuerza está ahí.
Es mucho más "barato" para un proyecto enano/pequeño/mediano dejar que otros te auditen . Está claro que para alguien grande, quizá sea mejor el "yo me lo guiso, yo me lo como".
3) Yo no digo que tener el código a la vista se más seguro. Yo digo que no tengo claro que sea más inseguro, porque también reporta ciertas ventajas en cuanto a seguridad. No tengo una opinión clara a este respecto como la tienes tú.
Creo que en el software privativo, al no tener el código, solamente los crackers van a poder detectar fallos de programación y explotarlos (amantes del IDA, SoftICE, olly, etc.). Eso es bueno y es malo, bueno porque te quitas de encima a todos los kiddies que solamente quieren tocar los cojones y malo porque hay mucha gente que quiere colaborar con los programas que más le facilitan la vida y que tiene serias sospechas de que en tal o cual módulo puede haber un fallo.
En el software libre pasa lo contrario: los crackers tienen mucha ventaja, tienen los planos a la vista, pero también tienen ventaja los programadores normales que quieren echar un cable, que creo que son más en proporción. Además, como estudiante de 4º de Psicología me animo a decir que un cracker verá menos motivante crackear un programa con el código abierto por estar más alejado de su idea de desafío o reto. Es un poco lo que pasa con las redes WiFi abiertas y las que tienen WEP: mola mucho más colarse en una que tiene WEP, para entrar en una abierta me voy a la de mi casa :-D
Ya te digo que no tengo una opinión 100% firme a este respecto, como la tienes tú.
Hace años seguí con interés el debate, focalizado en la web anti.security.is, ahora desaparecida. Se decían cosas muy interesantes y me convencían argumentos de los dos bandos, por lo que, usando lógica borrosa, me mantengo en un estado de indeterminación bastante serio en este tema O:-)
Si queréis echar un vistazo a la web, creo que los chicos de archive.org todavía tienen alguna copia de lo que fue: http://web.archive.org/web/20010721001413/anti.security.is/. Es risas el slogan: "save a bug, save a life" :-D
PD: Yo NO soy un experto en seguridad, no estoy al día, y ya hablamos de los piños y los alientos al ajillo. Me gustan las cosas de ese mundillo, pero tengo demasiados michelines mentales en muchos temas como para poder hablar con propiedad. Me dedico a otras cosas y tengo la seguridad como hobby. Siendo un campo tan complejo, no basta esa implicación (imagínate a alguien que tiene la neurocirugía como hobby, ¿a que no le dejas que te abra el cráneo? pero bueno, en un debate puede que sepa cosas).
PD2: Soy un poco varas y escribo mucho, pero eso da valor añadido al blog, ¿no? :-P
Hola Txipi:
ResponderEliminar1) Toi contigo.
2) Toi contigo.
3) Las técnicas cracker son con el compilado, afectan por igual al código abierto/cerrado y es mucho más sencillo que hacerlo leyendo código fuente, te lo garantizo que somos jugones de olly y softice. Crackear una WEP es como estar abierto :) (minutillos se tarda)
Respecto a la gente que quiere ayudar, me remito a las palabras de Crispin Cowan: "he asserted that security researchers were only interested in finding splashy bugs and posting them to security mailing lists."
Molan tus metáforas!! jejej
Un tipo que sabe algo de auditar código más que yo.
http://edans.blogspot.com/2006/09/vista-y-el-fin-del-imperio.html
ResponderEliminary lo interesante es... maligno.. como crackeas la wifi.. ¿desde un linux o desde un windows? :D
ResponderEliminarPues yo la crakeo desde Windows, como hemos hecho por toda España por la gira. La única tool que faltaba en Windows hace 1 año era la hacer el ataque 0, pero está hace tiempo conseguido.
ResponderEliminarEn http://hwagm.elhacker.net/ lo tienes todo en Windows.
Salute maligna.