Generación automática de exploits aprovechando los parches

La idea, hay que reconocerlo, es buenísima: crear automáticamente el programa que explotará la vulnerabilidad que trata de solucionar un parche mediante la información del mismo parche. La generación se realiza a través de la comparación entre el programa parcheado y el original. El artículo que desarrolla las posibles técnicas es Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications. Parece que la cosa últimamente va de diferencias binarias :) (como en Actualizando el kernel Linux sin reiniciar )

Más comentarios en Bruce Schneier: Reverse-Engineering Exploits from Patches, programming reddit: Automatic Patch-Based Exploit Generation y LtU: Automatic Patch-Based Exploit Generation.

Actualización: Como Apunta Drizzt en las publicaciones de la gente de bindiff se examina más detenidamente el tema de la comparación binaria. En la misma entrada Drizzt también aporta algún enlace más al respecto.

La misma entrada y más comentarios en Generación automática de "exploits" aprovechando los parches en barrapunto

Entrevista a Mario Bunge

Nota: Si eres lector de planeta código y sólo te interesa el desarrollo, sáltate esta entrada. Pero es un enlace que me parece de interés general :)

Vía Cuchitril Literario me encuentro con una buena pero breve entrevista a Mario Bunge. En ella se dice de la filosofía de Heidegger:

[...] se aprovechó de la tradición académica alemana según la cual lo incomprensible es profundo.

[...] fenomenología, existencialismo, esas cosas abstrusas que nadie entiende pero si usted dice que no entiende, pasa por tonto

O dicho de otro modo: no todas las veces que no entiendes algo es porque tú seas limitado. Plantéate que quizás no tenga ningún sentido...

Mario Bunge en la wikipedia

La misma entrada y más comentarios en Entrevista a Mario Bunge en barrapunto

Actualizando el kernel Linux sin reiniciar

Leyendo el blog de Daniel Stenberg me entero de que ksplice ofrece la posibilidad de hacer actualizaciones de seguridad en el kernel Linux sin reiniciar, siempre y cuando los cambios no supongan modificaciones semánticas en los datos. Según el autor este tipo de modificaciones son aproximadamente un 80% del total de vulnerabilidades críticas. Es, aparentemente, el sueño de muchos administradores de sistemas...

Más información en el artículo de presentación, Ksplice: An automatic system for rebootless Linux kernel security updates (pdf), en la lista del kernel, A system for rebootless kernel security updates y en programming.reddit.

Actualizando el kernel Linux sin reiniciar en barrapunto

La vida privada de volatile

El estándar de C(++) tiene unas cuantas esquinitas. Seguramente volatile es una de ellas. Para aclarar el significado exacto de este calificativo en Coding Relic han publicado La vida privada de volatile, en donde no solo se analiza la letra del estándar sino que se examina el código generado para MIPS en distintos casos.

Conviene recordar los posibles usos de volatile, así como para qué no debe usarse:

• How does the C "volatile" keyword really work? de Ian Lance Taylor. El resumen es bastante claro

  If you are using volatile for anything other than manipulating memory mapped hardware, or for very limited communication between threads, it is very likely that you are making a mistake. Think carefully about what volatile means and about what it does not mean.

• En la misma linea, Volatile: Almost Useless for Multi-Threaded Programming
• Varias discusiones en usenet: C++, volatile member functions, and threads, volatile guarantees? y Memory Barriers, Compiler Optimizations, etc., todas ellas en comp.programming.threads
• Una discusión sobre lo que es, que no es y que quizás debiera ser volatile en Should volatile Acquire Atomicity and Thread Visibility Semantics?, lo que lleva a arreglar el modelo de memoria de C++.

La vida privada de volatile en barrapunto

La aritmética de punteros, su desbordamiento y la seguridad

Me he enterado vía el valle del viento helado de una nueva polémica acerca de gcc y su implementación. El hecho es que gcc cambió su comportamiento en cuanto a comparaciones entre punteros incrementados y ha provocado muchos meses después una alerta de seguridad desproporcionada y según los desarrolladores de gcc, falsa (Se puede oír desde aquí el ruido y la furia)

El caso es que, entrando en profundidad, es una optimización casi "trivial" que hace que p + C1 < p + C2 pase a ser C1 < C2 sin tener en cuenta el posible desbordamiento (overflow) de ambas operaciones. Hay que decir además que el estándar (de C y de C++) declara no definido el valor del resultado de la suma entre un puntero y un entero cuando se sobrepasa el tamaño del objeto al que apunta.

Es muy importante este último punto, porque deja traslucir un error de concepto: la comprobación de overflow propuesta en la alerta(*) es muy burda porque sólo se comprueba el desbordamiento de la operación aritmética, no que nos estamos saliendo del rango permitido. Sin embargo lo que deben saber el programador y el programa a la vez, cuando están manejando aritmética de punteros es cual es el desplazamiento (offset) máximo, de cuanta memoria se dispone. Si eso no lo sabe, es inútil cualquier otra comprobación...

Hay que hacer notar además que la optimización de la que se habla aquí la aplican casi todos los compiladores y lo que provoca la alerta es en realidad el cambio de comportamiento, no que sea incorrecto.

También recuerda esto que es muy mala política basar el código en detalles de implementación específicos de la plataforma. En este caso y en muchos otros, los desarrolladores de gcc tiran de cita del estándar para argumentar sus decisiones. Los usuarios se quejan, llamándoles abogados del lenguaje (language lawyer) pero en momentos como esos hay que recordar que probablemente están defendiendo sus decisiones de implementación y lo importante de esas decisiones para el éxito de una tecnología.

(*)char *buf;
int len;
len = 1 << 30;
if (buf+len < buf){ Overflow }

La aritmética de punteros, su desbordamiento y la seguridad en barrapunto

Un par de enlaces más (sobre C++)

Sólo un par de enlaces más para complementar la entrada anterior, la entrevista con Stroustrup (lástima que hayan salido después, hubiesen quedado bien en la misma entrada...)

• La entrevista de Strosutrup comentada en Slashdot, sobre todo desde el punto de vista de la enseñanza del lenguaje. Como siempre, comentarios a la vez encendidos e interesantes...
• Trip Report: February/March 2008 ISO C++ Standards Meeting de Herb Sutter en el que se repasa las últimas incorporaciones a C++0x. Destaca, por supuesto, la incorporación de funciones lambda y clausuras. Pero hay más, como la herencia de constructores...

Un par de enlaces más (sobre C++) en barrapunto