MySQL身份认证漏洞 升级到5.5.24可修正

系统 Linux
MySQL爆出了一个很大的安全漏洞,几乎影响5.1至5.5的所有版本。出问题的模块是登录时密码校验的部分(password.c),在知道用户名的情况下(如root),直接反复重试(平均大约256次)即可登入。MySQL发布5.5.24的时候,修正了这个BUG。

我今天早上打开电脑,在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。

漏洞分析:

出问题的代码如下

/*
    Check that scrambled message corresponds to the password; the function
    is used by server to check that recieved reply is authentic.
    This function does not check lengths of given strings: message must be
    null-terminated, reply and hash_stage2 must be at least SHA1_HASH_SIZE
    long (if not, something fishy is going on).
  SYNOPSIS
    check_scramble()
    scramble     clients' reply, presumably produced by scramble()
    message      original random string, previously sent to client
                 (presumably second argument of scramble()), must be
                 exactly SCRAMBLE_LENGTH long and NULL-terminated.
    hash_stage2  hex2octet-decoded database entry
    All params are IN.

  RETURN VALUE
    0  password is correct
    !0  password is invalid
*/

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时代。

原文链接: http://www.udpwork.com/redirect/7463

 

责任编辑:yangsai 来源: udpwork
相关推荐

2012-03-13 16:38:55

GalaxyAndroid 4.0

2013-09-18 09:56:47

WindowsWindows 8.1

2011-09-27 09:13:16

Ubuntu 11.0

2011-02-18 09:06:15

ChromeChrome DevLinux

2020-01-13 10:00:32

升级Windows 10Windows

2010-05-24 17:33:43

MySQL数据库

2009-08-02 08:54:46

Windows 7 R系统升级

2023-08-04 19:41:53

UbuntuLinux

2022-09-12 21:10:42

LinkerdKubernetes

2015-07-29 10:21:03

微软Windows 10升级

2017-09-06 17:30:41

网站升级HTTPS

2013-12-26 14:54:58

Windows 8.1微软

2013-11-27 09:38:11

OpenSUSE 13OpenSUSE 12

2023-06-13 10:44:51

Debian 11Debian 12

2022-08-28 20:34:42

LinuxLinux Mint

2021-10-20 12:47:06

UbuntuUbuntu 21.1Linux

2012-10-11 09:43:34

2013-05-20 10:39:55

MariaDB

2011-03-31 13:39:14

mysql3mysql5乱码

2023-01-31 11:33:36

点赞
收藏

51CTO技术栈公众号