MySQL o cómo es posible dar por válida una contraseña incorrecta

En adelante nos referiremos a MySQL pero todo lo estudiado es totalmente válido para MariaDB.

El 9 de junio, Sergei Golubchik publicó en la lista de correo «Full Disclosure» los detalles de un error en algunas versiones de MySQL. Debido a un manejo incorrecto del valor devuelto por la función «memcmp» era posible que el sistema diera por correcta una contraseña diferente a la almacenada por el sistema.

Con esta simple prueba de concepto, era posible detectar un sistema vulnerable:

Tal como apunta el propio Golubchik, la vulnerabilidad se producía dependiendo de la librería estándar que use MySQL en el sistema donde se ha instalado. Por ejemplo la implementación de «memcmp» en la libc de BSD no sería vulnerable, al igual que la implementación «inline» que usa el compilador «gcc«. Sin embargo «glibc«, la librería presente en la mayoría de los sistemas Linux, sí lo es.

Veamos cómo se produce la vulnerabilidad comenzando por el proceso de autenticación de MySQL.  La contraseña nunca viaja en texto plano cuando se efectúa la autenticación con el servidor MySQL.

En realidad cuando el cliente inicia la conexión con el servidor, este le envía una cadena aleatoria. El cliente la recibe y la usa como semilla para obtener un hash SHA1. Las operaciones que efectúa el cliente son las siguientes:

Visualmente en pseudocódigo quedaría así:

enviar(xor(sha1(contraseña), sha1(text_del_servidor, sha1(sha1(contraseña)))));

Sobre el valor recibido por el servidor se efectúan las operaciones en orden inverso, obteniéndose el hash de la contraseña empleada por el usuario. Este hash es comparado usando la función «memcmp» contra el hash de la contraseña almacenado en el servidor.

Veamos el código antes de la corrección, la función donde se produce la llamada a «memcmp» es llamada «check_scramble» y se encuentra en

«sql/password.c»:

La cabecera de la función:

               const uint8 *hash_stage2)

{…

y la línea vulnerable:

}

Según la especificación de la función «memcmp«, esta compara tantos bytes como indica el tercer parámetro de las direcciones apuntadas por el primer y segundo parámetros. Esta función irá comparando byte a byte y en cuanto encuentre una diferencia la devolverá, signo incluido. Si el primero es menor devolverá la diferencia negativa y si es mayor será positiva. Finalmente, si los dos bloques de bytes son iguales, devolverá 0.

Como podemos observar, si «memcmp» devolviese 0, la contraseña es correcta.

De la documentación en sql/password.c:

 RETURN VALUE

El problema es que «memcmp» no va a devolver ‘0’ o no ‘0’, sino un valor entero (int). Dicho entero es convertido al valor que retorna «check_scramble» que es del tipo «my_bool«

«my_bool» está definido en el archivo include/my_global.h como sigue:

typedef char               my_bool

Esto quiere decir el valor devuelto por «memcmp» será truncado a un char posibilitando que el resultado finalmente sea un 0 interpretado incorrectamente.

Idealmente ese «memcmp» debería retornar un 0 o 1 y es lo que el parche que soluciona la vulnerabilidad contempla:

La diferencia es la aplicación de «test» sobre el resultado devuelto por «memcmp«. Dicha macro está definida en include/my_global.h:

#define test(a)            ((a) ? 1 : 0)

Ahora simplemente se trata de una operación lógica. Si hay un valor distinto de 0 devolverá un 1 (o lo que es lo mismo un «!0») el cual indica que la contraseña no es correcta.

La vulnerabilidad tiene asignado el CVE-2012-2122 y se consideran vulnerables las versiones de MySQL/MariaDB hasta la 5.1.61, 5.2.11, 5.3.5, 5.5.22.

Security vulnerability in MySQL/MariaDB sql/password.c

HD Moore