bitscn.com
在seclists中看到一个很惊人的thread:http://seclists.org/oss-sec/2012/q2/493mysql爆出了一个很大的安全漏洞，几乎影响5.1至5.5的所有版本。出问题的模块是登录时密码校验的部分(password.c)，在知道用户名的情况下(如root)，直接反复重试(平均大约256次)即可登入。不过，mysql身份认证的时候是采用3元组，username,ip,password。如果client的ip在mysql.user表中找不到对应的，也无法登陆。
这个bug实际上早在4月份就被发现了，今年5月7号，mysql发布5.5.24的时候，修正了这个bug。
漏洞分析：
出问题的代码如下
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]之内。glibc的经sse优化后的代码，不是如此。所以这个bug只在特定的编译环境下才会触发：即编译mysql的时候加了-fno-builtin，并且所使用的glibc是经sse优化后的(一般系统自带的都是如此)。这里所说的glibc是指linux的glibc，freebsd的libc不受影响。
总的来说这个bug还是比较严重的，上次mysql出现这样的bug还是在3.23/4.0时代。
bitscn.com