Hardening de binarios (V) – UBSan

El comportamiento indefinido en C/C++ es causado cuando no existen restricciones en el comportamiento del programa; es decir, cuando el estándar no especifica qué debe hacer la implementación, esta es libre de hacer lo que le parezca. En los tiempos de Usenet, el grupo comp.std.c acuñó el término nasal demons para referirse al comportamiento indefinido de C, ya que “When the compiler encounters [a given undefined construct] it is legal for it to make demons fly out of your nose”.

Ejemplos típicos de nasal demons en C/C++ son la división por cero, el uso de una variable no inicializada, desreferenciar un puntero a NULL etc, algunos de estos casos ya están corregidos, pero aún es posible compilar programas con comportamiento no definido. Por ejemplo, dado el siguiente programa:


int function() { }
int main(){
int array[1];
array[-1] = 1;
int b;
if (b)
printf("lucky!\n");
printf(“%f\n”, 1.01 / 0.00);
int ret = function();
return 0;}

¿Qué hará el compilador cuando tratemos de asignar 1 a array[-1] ?
¿Tendremos suerte?
¿Qué pasa cuando dividimos por cero, en enteros, floats y doubles?
¿Qué retorna function?

Para detectar este tipo de errores podemos usar UBSan (Undefined Behavior Sanitizer), el detector de comportamiento indefinido en tiempo de ejecución para GCC y Clang. UBSan instrumenta el programa para detectar de forma general el comportamiento indefinido con -fsanitize=undefined, o se pueden instrumentar opciones específicas, como -fsanitize=return para comprobar que no se llegue al final de una función no void sin retornar un valor, -fsanitize=null para asegurar que no de-referenciamos un puntero a NULL, -fsanitize=vprt para que las conversiones entre clases base y derivadas tengan el tipo correcto…

Las vulnerabilidades por comportamiento indefinido en C/C++ están a la orden del día, siendo las más comunes el bad casting y el use-after-free, que afectan gravemente a navegadores, servidores web etc. Además de UBSan, DANGNULL, CaVer y TypeSan son algunos checkers de esta clase de errores.

¿Es esto suficiente? Lo descubriremos en los siguientes posts.

Irene Díez
Acerca de
Investigadora de DT
Expertise: Operating systems, program analysis