Después de escuchar un breve comentario de un periodista sobre la seguridad del nuevo Windows Vista, en relación con el SpyWare y Virus, cuya conclusion fue que nunca se logrará construir software libre de fallos, no he podido evitar dirigirme aqui y escribir este post.

Empecere diferenciando las tres clases de fallos que se dan en toda construccion software:

1. Bugs en los requisitos: Son aquellos que afectan a la funcionalidad requerida por el cliente y que no han sabido ser entendidos por las personsas encargadas de esta fase. Un par de ejemplos podria ser incluir solo el tipo de moneda en pesetas o que el motor no debe superar las 3000 rpm.
2. Bugs en el diseño: Aqui es donde empiezan a surgir los fallos que nos interesan, aquellos relacionados con la seguridad o funcionalidad crítiticas de la aplicacion. Los fallos surgen por considerar triviales, hacer caso omiso o por simple desconocimiento de los casos en los que se está trabajando. Ejemplos serían el fallo de seguridad que hace poco se presento en freeVNC o no contemplar el caso en que si el cohete supera la inclinacion permitida hay que reectificar la trayectoria.
3. Bugs en la implementación: En este ultimo tipo entrarían los fallos de tipo tecnologico, es decir, provocados por no entender las herramientas con las que se está trabajando. Los archiconocidos overflows o fallos en el parseo de cadenas son simplemente algunos, de los que seguramente sabreís mas que yo.

Desde mi punto de vista, estoy seguro que se conseguiran reducir los bugs en las aplicaciones a medida que se van estandarizando las tecnicas para construir las mismas, llegando a alcanzar aplicaciones 100% libres de bugs en la mayoria de los casos.

(más…)

Leyendo el programa de la BlackHat, me ha llamado la atención una conferencia, que precisamente parece que se celebra hoy, aunque por desgracia creo que ninguno de «48Bits» vamos a estar por allí :-(. Se trata de un campo que aunque es sobradamente conocido, creo que en muchos casos no se trata con la suficiente importancia por los programadores de aplicaciones, quizá esto sea debido en parte a que este tipo de vulnerabilidades parecen no estar entre las más investigadas por los buscadores de las mismas.

Es un tema del que hemos hablado entre algunos de los que hacemos 48Bits, cuando nos hemos puesto a analizar algún programa para buscarle las «cosquillas». Existen varias maneras de implementar mecanísmos de este tipo, entre los que se encuentran «Named Pipes» y memoria compartida, me refiero sobre todo a IPC entre procesos ejecutándose en una misma máquina. El desarrollo de multitud de aplicaciones entre las que se encuentran muchas relacionadas con la seguridad informática, requieren un diseño tal que cierta parte de ellas se ejecuta con privilegios más elevados que otras, siendo necesario que exista un canal de comunicacion entre ambas, es aquí cuando se suelen utilizar este tipo de mecanismos. Muchas veces el problema radica precisamente en la seguridad asociada a este tipo de objetos (qué usuarios o procesos pueden acceder a ellos y/o modificarlos), otras veces en la validación de los datos contenidos o incluso en el mal uso de los objetos utilizados para sincronización.

Parece que en la conferencia se va a hablar de cómo trabajar con este tipo de objetos e incluso se van a presentar algunas herramientas orientadas a la automatización de «fuzzing» sobre ellos, interesante 😀

Googleando un poco he encontrado algún artículo interesante sobre el tema, aunque supongo que después de la blackhat podremos ver las herramientas presentadas y quizás un resumen de la conferencia.

Un saludo!

Hemos abierto unos foros de discusión en 48bits, el acceso de lectura es libre para todos y el de escritura para cualquier usuario que se registre. En el foro se comentarán noticias, cuestiones técnicas sobre programación o análisis de vulnerabilidades, malware, etc… que en principio no son tan relevantes o no interesan a tanta gente como para tratarlas en el blog, aunque la intención es que el resultado de algunos de los comentarios que esperamos tratar allí pudieran pasar a portada en el blog.

Los foros tienen dos secciones una en castellano y otra en inglés con las mismas categorías, de esta manera esperamos poder llegar a todo el que lo desee sin dejar de recibir el aporte de la comunidad castellano hablante, que como bien sabemos en muchas ocasiones no dominamos todo lo que deberíamos inglés 🙁

 Un saludo y … a postear! 😀

Acabo de hacer publica GALD v1.0 una utilidad, que personalmente me resulta bastante util, dedicada a la deteccion de perdidas de memoria y double-freed pointers.

La ventaja sobre otros metodos es que no se necesita reemplazar las llamadas C standar malloc(), calloc(), realloc() o free(), permitiendo asi tener un sistema de detection de memory leakages implemente incluyendo una cabecera C y recompilando la aplicacion, ni emular una CPU lo cual ralentiza mucho la aplicacion e incluye basura proveniente de todas las librerias utilizadas.

Una vez lanzado el ejecutable por la salida estandar de errores apareceran trazas cuando la memoria es reservada y liberada junto con el nombre del fichero de codigo y la correspondiente linea. Para facilitar su comprension he incluido un simple escript que presenta un resumen una vez la aplicacion ha terminado.

(más…)

Hace un tiempo en el departamento de desarrollo de una conocida multinacional informatica.

Una maquina de 64 procesadores hace estragos para procesar unos pocos millones de entradas de datos, cuando otras maquinas inferiores procesan 10 veces mas.
El manager del proyecto decide pedir un informe al departamento de sistemas, para ver si puede ser debido a algun problema de la maquina o configuracion del SO.

Una semana despues de haberlo solcitado, una chica baja un informe de unas 150 paginas, en el que se podia leer la siguiente conclusion:

«El sistema operativo y la maquina estan en perfectas condiciones, puesto que no se observan cambios de contexto ni llamadas al sistema.»