En estos últimos días ha habido cierto revuelo con la vulnerabilidad en la autenticación de MySQL y MariaDB (el fork tras la adquisición de Sun por Oracle). El fallo permite, en algunas versiones, evadir el proceso de autenticación y obtener acceso a la base de datos.
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:
for i in `seq 1 512`; do echo 'select @@version;' | mysql -h 127.0.0.1 -u root mysql --password=X 2>/dev/null && break; done
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.
$ mysql --host=localhost --user=usuario--password=contraseña
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:
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:
my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) {... y la línea vulnerable: ... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
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 0 password is correct !0 password is invalid
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"
¿Cómo está definido "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:
return test(memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE));
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.
Más información:
Security vulnerability in MySQL/MariaDB sql/password.c http://seclists.org/oss-sec/2012/q2/493
HD Moore https://twitter.com/hdmoore/status/211991006630002688
String/Array Comparison http://www.gnu.org/software/libc/manual/html_node/String_002fArray-Comparison.html
~mysql/mysql-server/5.1 https://bazaar.launchpad.net/~mysql/mysql-server/5.1/view/3560.10.17/include/my_global.h#L1108
FUENTE :http://www.laflecha.net/canales/seguridad/noticias/mysql-o-como-es-posible-dar-por-valida-una-contrasena-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:
for i in `seq 1 512`; do echo 'select @@version;' | mysql -h 127.0.0.1 -u root mysql --password=X 2>/dev/null && break; done
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.
$ mysql --host=localhost --user=usuario--password=contraseña
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:
- Obtiene el SHA1 de la contraseña empleada por el usuario (en el parámetro --password).
- Obtiene el SHA1 del sha1 anterior.
- Obtiene el SHA1 del paso anterior pero usa como semilla el texto enviado por el servidor.
- Sobre este último valor se hace una operación XOR con el sha1 de la contraseña y el resultado se envía al servidor.
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:
my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) {... y la línea vulnerable: ... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
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 0 password is correct !0 password is invalid
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"
¿Cómo está definido "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:
return test(memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE));
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.
Más información:
Security vulnerability in MySQL/MariaDB sql/password.c http://seclists.org/oss-sec/2012/q2/493
HD Moore https://twitter.com/hdmoore/status/211991006630002688
String/Array Comparison http://www.gnu.org/software/libc/manual/html_node/String_002fArray-Comparison.html
~mysql/mysql-server/5.1 https://bazaar.launchpad.net/~mysql/mysql-server/5.1/view/3560.10.17/include/my_global.h#L1108
FUENTE :http://www.laflecha.net/canales/seguridad/noticias/mysql-o-como-es-posible-dar-por-valida-una-contrasena-incorrecta
