CVE-2012-2122: MySQL身份认证漏洞

http://seclists.org/oss-sec/2012/q2/493


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




### 关于 MySQL 输入验证错误漏洞 CVE-2022-21454 #### 漏洞详情 CVE-2022-21454 是指在 MySQL 数据库管理系统中的输入验证存在缺陷。当处理特定类型的 SQL 查询时,如果用户提供了恶意构造的数据作为参数,则可能导致服务器崩溃或执行任意代码。此问题影响多个版本的 MySQL 和 MariaDB,在某些情况下可能被远程攻击者利用来实施拒绝服务(DoS)攻击或其他更严重的后果。 具体来说,该漏洞存在于解析 JSON 文档的过程中[^3]。由于未能正确地检查传入数据的有效性,使得未经适当清理的内容能够绕过正常的防护机制并触发内部逻辑错误。这不仅限于直接通过应用程序接口提交的信息;还包括任何可以间接传递给数据库引擎的地方,比如存储过程调用、事件调度器任务等。 #### 影响范围 受影响的产品及其版本如下: - Oracle MySQL Server 8.0.27 及之前版本 - Percona Server for MySQL 8.0.x 系列 - MariaDB 10.6.x, 10.5.x, 10.4.x 各分支 对于企业级部署而言,及时评估当前使用的软件是否处于风险之中至关重要。建议管理员查阅官方发布的安全公告以获取最准确的影响列表[^3]。 #### 解决方法与缓解措施 针对这一安全隐患,厂商已经发布了补丁程序更新。为了防止潜在威胁的发生,强烈推荐采取以下行动: 1. **立即升级至最新稳定版**:安装由供应商提供的修复包是最有效的解决办法。例如,Oracle 已经在其后续发行版中解决了这个问题,如 MySQL 8.0.28 或更高版本。 2. **应用临时修补脚本**:如果无法马上进行全面迁移,可以通过修改配置文件的方式减少暴露面。设置严格的连接限制和资源控制策略有助于降低危害程度。此外,还可以考虑启用只读模式或将敏感操作迁移到隔离环境中运行。 3. **加强审计日志记录强度**:确保启用了详细的查询历史追踪功能,并定期审查异常活动迹象。这样可以在早期发现可疑行为并作出响应。 4. **强化身份认证体系**:采用多因素验证(MFA),并对不同级别的权限进行精细化管理。最小化特权原则同样适用于数据库账户分配场景下,即授予刚好足够的访问权利完成必要的工作即可。 ```sql ALTER USER 'your_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'StrongPassword!'; FLUSH PRIVILEGES; ``` 以上SQL语句用于更改指定用户的密码为强随机字符串形式,从而提高安全性[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值