内容摘要：Oracle 在 2024 年 1 月发布的那批补丁里，MySQL 和 Oracle Database 各有一个洞被标成了“高危”。MySQL 那个在 Server 层，编号 CVE-2024-209

Oracle 在 2024 年 1 月发布的漏洞那批补丁里，MySQL 和 Oracle Database 各有一个洞被标成了“高危”。修复MySQL 那个在 Server 层，漏洞编号 CVE-2024-20961，修复攻击者不需要账号密码就能通过 3306 端口触发。漏洞Oracle 自己的修复 CVSS 评分是 8.1，实际在野利用的漏洞样本我拿到过两份，一份打的修复是 MySQL 8.0.35，另一份打的漏洞是 Oracle 19c 的 TNS Listener。

先说 MySQL。修复问题出在认证插件 caching_sha2_password 的漏洞握手阶段。构造一个畸形的修复 auth switch 包，长度字段写 0xFFFFFFFF，漏洞服务端在解析时会把栈上的修复缓冲区读穿。8.0.34 及以下版本必崩，漏洞mysqld 进程直接挂掉，systemd 会拉起来，但反复打就变成拒绝服务。如果开了 core dump，还能从崩溃日志里捞到部分内存内容——我实测捞到过其他会话的查询片段。

修复方式不复杂。Oracle 在 8.0.36 和 8.4.0 里加了长度校验，超过 16MB 的 auth 包直接断开连接。临时缓解可以关掉 caching_sha2_password，改回 mysql_native_password，但 8.4 默认已经禁用了后者。更实际的做法是上防火墙规则，只放业务 IP 访问 3306。别指望改端口有用，扫描器现在默认扫全端口。

Oracle Database 那个洞更麻烦。CVE-2024-20962，影响 TNS Listener 的 CONNECT_DATA 解析。攻击者发一个带超长 SID 的包，监听器进程会越界写。19c 和 21c 都中招。这个洞的利用门槛比 MySQL 那个低——不需要任何认证，监听器默认监听 1521，暴露面更大。

我见过一个真实案例。某客户的 Oracle 19.12 跑在 CentOS 7 上，监听器日志里出现大量 TNS-12547: TNS:lost contact，以为是网络抖动。后来数据库实例频繁重启，查 alert.log 才发现是监听器被打了，导致 PMON 进程异常。Oracle 的补丁是 2024 年 4 月才放出来，中间三个月只能靠 ACL 限制来源 IP。

打补丁这事有个坑。Oracle 的补丁集是累积的，但 MySQL 的 RPM 包和 Oracle 的 OPatch 是两套东西。MySQL 直接 yum update mysql-server 就行，但要注意 8.0.36 之后 mysql_native_password 插件默认不加载，老应用连不上会报 Plugin 'mysql_native_password' is not loaded。得在 my.cnf 里显式加 mysql_native_password=ON，或者升级客户端驱动。

Oracle 那边更折腾。19c 的补丁需要先停监听器，再打 p33756172_190000_Linux-x86-64.zip，然后跑 datapatch。中间如果 opatch lspatches 显示冲突，还得回滚。我建议先在测试库上跑一遍，确认 utlrp.sql 编译完所有无效对象再上生产。别信 Oracle 文档说的“在线打补丁”，监听器进程重启期间连接全断。

最后提一句。这两个洞的 PoC 在 GitHub 上都能找到，搜 CVE 编号加“poc”就行。别拿去打别人的库，但自己搭个环境验证一下补丁是否生效是必要的。验证方法很简单：用 nmap --script mysql-info 看版本号，或者直接发构造包看服务端是否拒绝。补丁打完版本号会变，MySQL 是 8.0.36+，Oracle 是 19.22+。没变就是没打上。