lunes, enero 14, 2008

Balas de Plata para Fallos Informáticos

Zapatero a tus zapatos (joder! Vaya frase que he ido a elegir en periodo electoral…) quiero decir, que carpintero a tus carpinters… joder, vale, como dice la canción “si naciste pa martillo del cielo te caen los clavos”. Uff, creo que después de este párrafo nadie tiene ni puta idea de lo que quiero decir. Empecemos otra vez:

Coverity, la empresa encargada de comenzar en enero de 2006 el proyecto bug hunting, ha estado, está y estará analizando el código utilizado en muchos proyectos Open Source. Dicho análisis se realiza desde un punto de vista de seguridad de código (no de seguridad del producto). La herramienta utilizada por Coverity es una Analizador Estático de Código. El funcionamiento de estas herramientas es “sencillo” de entender. La idea principal es tener todos los fallos conocidos que provocan defectos, malfuncionamientos o bugs de seguridad patronizados en una base de datos.

La herramienta se lee el código del producto y busca los patrones dentro del código. Cuando la herramienta no ha encontrado ningún patrón dentro del código analizado, hemos de suponer que el analizador ha terminado su función. ¿Eso quiere decir que la aplicación es segura? Según el titular de la noticia escrita por este escritor, parece que Sí: 11 open-source projects certified as secure


Pero la realizad es que..¡Ni de broma! Por varios motivos:

- El código puede no tener ningún fallo y la aplicación tener cagadas de seguridad en cuando a concepto.

- Los analizadores son aplicaciones que no son perfectas y ninguno reconoce todos los fallos posibles. De hecho, son herramientas magnificas, que aumentan la calidad del software y reducen al mínimo el número de bugs que puede tener un código, pero la perfección está aún lejos. Un programa analizado reducirá más número de bugs cuanto mejor sea el analizador de código utilizado. Spectra utiliza desde al año 2003 un proceso de análisis de código estático (junto con otros de análisis dinámico) dentro del proceso de desarrollo marcado por el SDL y como se ha visto el número de bugs se ha reducido drásticamente, pero… ¿han desaparecido todos los fallos de seguridad? ¿Se puede decir que es seguro todo el código?. Ok, si fuera así, basta con comprar una herramienta y listo.

- Los desarrollos son cambiantes y con cada nueva línea de código metida en un nuevo proyecto se pueden introducir fallos, así que un escaneo solo sirve en un código concreto y deberá ser re-analizado en cada actualización.

- La seguridad cambia. Cada día aparecen nuevas formas de atacar un sistema, nuevas maneras de explotar algo, nuevas formas de saltarse las protecciones. No se pueden conocer los defectos que aún no se han detectado. ¿Cuántos habéis lanzado escanners de vulnerabilidades contra los Retos Hacking y no habéis sacado nada? 11 proyectos con 0 defectos encontrados es algo maravilloso y habla mucho y bien del esfuerzo que se está realizando, pero… tanto como que los proyectos sean seguros…¡Ojala fuera así de fácil el análisis de seguridad!

Si queréis más información de esto, uno que no sabe tampoco mucho de esto, el amigo Michael Howard, escritor de los libros: Writing Secure Code, 19 Deadly Sins of Software Security, The Security Development Lifecycle y Writing Secure Code for Windows Vista lo explica mucho mejor y en menos líneas:

"Open-source projects certified as secure" – huh?

Saludos Malignos!

11 comentarios:

Anónimo dijo...

"Certificado como seguro"? Todos sabemos que no existe software 100% seguro pero una auditoría de código (manual o automatizada) ayuda a subir el listón. Lo mismo aplica al SDL de m$ y a cualquier proceso de "securización" :)

No veo por qué tanto alarmismo...

Por cierto, he "publicado" la tool que utilicé para la tercera fase del reto #5. Se llama
"lsbstego":
http://www.rs-labs.com/exploitsntools/

En realidad, el .c no se puede descargar todavía (está lista pero le he
hecho un chmod 0 :)). He dejado la descripción de la tool como adelanto, podría servir como última pista del reto y como ayuda para los que todavía estén dando las
últimas coletadas (¿Pedroooo??)

El día 15 por la mañana (se supone que ya estará el reto oficialmente
cerrado) le hago chmod 644.

-r

Chema Alonso dijo...

Ya,ya, si se que es una técnicolessada...

Unknown dijo...

Para mi el problema básico está en que el "periodismo digital" bebe de las mismas fuentes que el escrito y por tanto también tiene tendencia a las noticias "espectaculares" muchas veces basadas en la simplificación de conceptos (y además a veces simplificaciones erróneas). Es más espectacular decir que han "certificado aplicaciones seguras" que no "se ha pasado un analizador de código sin encontrar problemas".

Coincido con romansoft en que al menos si leemos entre lineas lo que ha ocurrido es que seguramente esas aplicaciones han subido el listón de seguridad.

ptarra dijo...

Maligno,

Creo que hay varios cientos de entradas en distintos blogs haciendose eco de una manera u otra de la "noticia".

Lo importante no es que un imbécil cometa un error semántico (como es el caso) sino que se señalan 11 proyectos open source en los que según la propia Coverity la implicación de sus desarrolladores por corregir los bugs es muy alta.

Es conocido el caso de algunos proyectos cuya preocupación por la seguridad ha sido nula (phpBB, phpNuke...), por lo cuál, no está mal disponer de referencias objetivas respecto a la actitud de los desarrolladores respecto al proceso de la seguridad, ¿no?

Un saludo,
Pedro

Chema Alonso dijo...

@xavier, sí, es un problema de periodista buscando titular, tú lo has dicho.

@ptarra, es una muy buen opción, de hecho lo ha hecho coverity, que es una buena idea. Certificaciones como el CMMI ayudan también a la hora de saber que empresa coger para desarrollos, pq no va a servir esta? Lo que me jode es el titularismo técnicolessico!!!

Saludos, que estuve en Pamplona y no pasaste a saludar!! perrro!!

Diego dijo...

Los de Coverity es evidente que lo único que quieren es que el mundo del software libre le haga publicidad gratis por la cara. Y la cosa es que hasta el momento les está saliendo de puta madre...

ptarra dijo...

Maligno,

Ya sé que estuviste en Pamplona, pero precisamente ese día el que no estaba en Pamplona era yo.

Como buen miembro de las fuerzas del bien me gusta hacer apostolado, o ser misionero, o qué se yo, y estoy tratando de expandirme por territorios limítrofes.

Un saludo,
Pedro

Anónimo dijo...

Hola Maligno!
Te expongo acá mi duda porque creo que al ser un blog si lo coloco en el post correcto puede que no lea.

Estoy interesado en leer todos los posts técnicos de intrusión y demás de tu blog. Me podrías dar algún consejo a la hora de buscarlos sin tener que navegar por todas las entradas desde que se creo el blog. Muchas gracias y enhorabuena.

Anónimo dijo...

@anonimo:

Prueba con los tags de la parte derecha, si no con las categorias :).

Anónimo dijo...

Una cosa que no he leido y no logro entender.

La empresa en sí tira una código en PHP (sea cual sea) lo analiza con un analizador de código estatico y como devuelve 0 fallos, ¿PHP es seguro?.

Bien si es así apaga y vamonos que para que estamos nosotros.... y lo mejor llevo toda la tarde leyendo comentarios de conocidas páginas de l1nUx f4nb07s (véase /. y un largo etc) diciendo boberias sobre que tiene que decir MS a esto que si blabla... pero.. ¿!!!Qué capuyo escribiria algo así!!!?

En fín un buen intento de viral que como habla de Open source y seguridad se colara en un buen número de páginas..

Chema Alonso dijo...

@ptarra, deja de conquistar territorios y disfruta un poco de relax! ;)

@Diego Calleja, yo creo que son buenos, y hacen buen trabajo. Está claro que le viene bien la publicidad del SL y la frase de Andrew Morton en la web es sintomática, pero yo creo que Coverity.COM, hace el trabajo de una empresa. Están en su derecho, ¿no?

@anónimo, usa las tags, y las opciones de buscar, pero sí que llevo tiempo pensando en hacer un post resumen de artículos técnicos, ya lo pondré. Saludos!

@sirw2p, lo que dice Coverity es que la versión evaluada de PHP no ha tenido ningún defecto tras ser evaluada con su analizador de código estático y que además su equipo tiene buena predisposición para arreglar los fallos, el resto... marketing viral generado al margen de ellos. ;)

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares