宝塔报 dhcp 漏洞？一次 CentOS 版本号引发的误报

结论先说：宝塔报的这三个 dhcp 漏洞是误报。服务器上装的就是它要求的版本，只是 CentOS 换了个名字，扫描器没认出来。

事情是这样的

一台 CentOS 7 服务器上，宝塔面板的安全扫描报了三条系统软件漏洞：

dhcp-common-4.2.5-83.el7.centos.2 版本低于 4.2.5-83.el7_9.2
dhcp-libs-4.2.5-83.el7.centos.2   版本低于 4.2.5-83.el7_9.2
dhclient-4.2.5-83.el7.centos.2    版本低于 4.2.5-83.el7_9.2

乍一看像是漏了补丁。但仔细对比会发现，两个版本号都是 4.2.5-83，末尾也都是 .2，只有中间一个写 el7.centos、一个写 el7_9。

排查：看一眼 changelog 就清楚了

判断补丁有没有打，最可靠的办法不是比版本号，而是看包自己的变更记录：

[root@banana2 ~]# rpm -q --changelog dhclient | head -20
* Mon Jun 10 2024 CentOS Sources <bugs@centos.org> - 4.2.5-83.el7.centos.2
- Roll in CentOS Branding

* Wed May 22 2024 Stepan Broz <sbroz@redhat.com> - 12:4.2.5-83.2
- Rebuild because of bind ABI changes related to CVE-2023-50387

* Thu May 27 2021 Pavel Zhukov <pzhukov@redhat.com> - 12:4.2.5-83.1
- Fix for CVE-2021-25217
...

从下往上读：

  1. 83.1（2021-05-27）：Red Hat 修复 CVE-2021-25217。
  2. 83.2（2024-05-22）：Red Hat 的重新编译，就是 RHEL 上的 4.2.5-83.el7_9.2，也就是宝塔要求的版本。
  3. 83.el7.centos.2（2024-06-10）：CentOS 在 83.2 的基础上只做了一件事——替换品牌标识（Roll in CentOS Branding）。

也就是说，宝塔要求的补丁已经完整包含在当前安装的包里。

为什么会误报

误报有两个原因叠加：CentOS 改了版本号的写法，而 RPM 的比较规则恰好把改后的名字判为更旧。

CentOS 会重命名 release 标签

CentOS 是拿 RHEL 公开的源码重新编译的。重编译时，它会把 RHEL 版本号里的 el7_9 替换成 el7.centos，代码本身不变。

RHEL 版本

CentOS 对应版本

内容

4.2.5-83.el7_9.2

4.2.5-83.el7.centos.2

配合 bind 修复的重编译（2024）

4.2.5-83.el7_9.1

4.2.5-83.el7.centos.1

修复 CVE-2021-25217（2021）

宝塔的漏洞规则显然是照着 RHEL 的安全公告写的，只认 el7_9 这种写法。

RPM 把「centos」判得比「9」旧

RPM 比较版本号时，会把字符串切成一段一段的数字和字母，逐段比较：

83.el7.centos.2  →  83 | el | 7 | centos | 2
83.el7_9.2       →  83 | el | 7 | 9      | 2

前三段完全相同。第四段一边是字母 centos，一边是数字 9。RPM 的规则是：数字段总是比字母段新。于是 el7.centos.2 被判为「低于」el7_9.2，尽管两者是同一份代码。

实际上，宝塔对 CentOS 7 上所有 el7_9.x 规则的包都可能触发同样的误报。

83.2 其实没修 dhcp 的漏洞

顺带一个有意思的细节：83.2 这次更新本身并不修 dhcp 的漏洞。

changelog 写得很明白：这是一次因为 bind 的 ABI 变化而做的重新编译。当时 bind 修复了 CVE-2023-50387（俗称 KeyTrap，一个 DNSSEC 验证时可被利用来耗尽 CPU 的拒绝服务漏洞），库的接口变了。dhcp 链接了 bind 的库，所以必须跟着重编译一次才能兼容。

换句话说，真正的安全修复在 bind 那边。如果要确认服务器对 KeyTrap 是安全的，该看的是 bind 的版本，而不是 dhcp。

怎么处理

  1. 在宝塔里忽略这三项。 已经确认是同一版本，没有任何需要升级的东西。
  2. 顺便检查 bind 的库是否已修复 KeyTrap。
rpm -q bind-export-libs bind-libs-lite

版本号中带 9.11.4-26.P2.el7_9.16 或更高即为已修复；更低的话执行 yum update bind-export-libs bind-libs-lite。

如果想亲自验证 RPM 的比较结果，可以装上 rpmdevtools 后运行：

rpmdev-vercmp 4.2.5-83.el7.centos.2 4.2.5-83.el7_9.2

它会告诉你后者「更新」，正好复现了宝塔的判断。

更值得关心的问题：CentOS 7 已经停更

注意 changelog 最上面那条的日期：2024 年 6 月 10 日。二十天后，2024 年 6 月 30 日，CentOS 7 正式停止维护。这个包很可能就是 CentOS 7 上 dhcp 的最后一次更新。

这意味着：

  • 这次是误报，但之后宝塔报出的漏洞会越来越多是真的，而且永远等不到官方补丁。
  • 官方镜像已下线，yum 需要改用 vault.centos.org 或国内镜像的 vault 源才能用。

如果是长期在用的生产服务器，建议尽快规划迁移到仍在维护的发行版，如 Rocky Linux、AlmaLinux 或 OpenCloudOS。

小结：扫描器说「版本过低」时怎么判断

漏洞扫描器本质上是在比字符串，而不是在检查代码。遇到类似告警，可以按这个顺序判断：

  1. 对比主版本号和末尾的数字。 如果只是 el7_9 与 el7.centos 这类发行版标签不同，很可能是同一个版本。
  2. 看 rpm -q --changelog。 上游的修复记录和 CVE 编号都在里面，这是最直接的证据。
  3. 试一下 yum update。 如果提示没有可用更新，说明已经是发行版能提供的最新版。

确认是误报就忽略；确认是真漏洞但发行版已停更，那该考虑的就不是打补丁，而是换系统了。

参考

posted @ 2026-10-22 18:33  sherlock-merlin  阅读(17)  评论(0)    收藏  举报