如果一个服务以 root 权限运行,并持续等待外部请求,那么无论它看起来多么不起眼,都是一个值得攻击的目标。NetworkManager 正是这样:CERT-Bund 在编号 WID-SEC-2026-2977 下发布了一份关于权限提升漏洞的通告,涉及 RHEL/CentOS 衍生发行版。如果你运营的 Root 服务器基于这类系统,现在就应该花点时间检查一下,而不是把这份通告埋在收件箱里。
- CERT-Bund 在编号 WID-SEC-2026-2977 下报告了一个通过 NetworkManager 实现的权限提升(Privilege Escalation)漏洞。
- 根据通告,受影响的是 RHEL/CentOS 衍生发行版——也就是说,AlmaLinux、Rocky Linux 或 CentOS Stream 等使用相同底层架构的发行版也在其中。
- NetworkManager 以 root 权限运行,并且在许多预装的服务器镜像中默认处于激活状态,哪怕你从未主动接触过它。
- CVE 编号、受影响版本和补丁状态只写在原始通告中——我们选择链接过去,而不是简化转述。
为什么偏偏是 NetworkManager
多年来,NetworkManager 一直是 RHEL 及其衍生系统中网络配置的标准组件:DHCP、静态 IP 地址、VPN 配置文件、DNS 设置——全都经由它处理。它作为系统服务以完整的 root 权限运行,并通过 D-Bus 对本地进程开放访问。正是这种组合——root 权限加上一个连权限较低的进程也能调用的接口——是权限提升漏洞的典型温床:本地攻击者,或者一个已经被攻陷的低权限进程,利用处理过程中的错误,以该服务的权限(也就是 root)执行命令。在许多用于 Root 服务器的预装 RHEL 衍生系统镜像中,NetworkManager 默认就是激活状态,完全不需要你在安装时主动选择它。
一个以 root 权限运行、并接受任何本地进程请求的服务,本质上是一个信任问题——而不仅仅是一个网络工具。
CERT-Bund 通告说了什么——以及我们刻意不重复的内容
通告 WID-SEC-2026-2977 将该漏洞归类为 RHEL/CentOS 衍生发行版上通过 NetworkManager 实现的权限提升。具体的 CVE 编号、CVSS 评分以及确切受影响的版本状态,会随着该通告的每次更新而变化——因此我们不在这里转述二手信息。
谁会受到影响
该通告针对的是 RHEL/CentOS 衍生发行版。这不仅包括 Red Hat Enterprise Linux 本身,还包括许多 Root 服务器运营者使用的二进制兼容重建版本,因为它们不需要 Red Hat 订阅:
| 发行版 | 与 RHEL 的关系 | NetworkManager 是否为默认组件? |
|---|---|---|
| Red Hat Enterprise Linux | 原版 | 是 |
| CentOS Stream | RHEL 的上游预发布版本 | 是 |
| AlmaLinux | 二进制兼容重建版本 | 是 |
| Rocky Linux | 二进制兼容重建版本 | 是 |
如果你使用的是 Debian 或 Ubuntu,系统通常会通过其他机制管理网络。但也不能完全排除 NetworkManager 的存在——它有时会被附带安装,比如随服务器上的桌面或 GUI 软件包一起安装。因此,在那里做个简单检查也无妨。
如何检查你的服务器
- 检查 NetworkManager 是否在你的服务器上已安装并处于激活状态。
rpm -q NetworkManager systemctl is-active NetworkManager - 记下已安装的版本号,以便稍后与通告中的补丁状态进行比对。
rpm -q --qf '%{VERSION}-%{RELEASE}\n' NetworkManager - 更新软件源并安装更新。
dnf makecache dnf update NetworkManager - 在没有
dnf的较旧系统上,改用yum。yum update NetworkManager - 重启该服务,让新版本真正生效。
systemctl restart NetworkManager - 在关闭当前 SSH 会话之前,检查网络连接是否正常。
ip a ping -c 3 <dein-gateway>
确认更新是否真的生效
重启之后,再检查一遍是值得的:将步骤 2 中的版本号与 rpm -q NetworkManager 的新输出进行比对。如果版本号或发行号更高了,说明更新生效了。此外,systemctl status NetworkManager 会显示该服务是否正常运行(状态为 active (running)),还是陷入了错误循环——如果是后者,就值得查看一下日志。
journalctl -u NetworkManager -n 50为什么在租用的 Root 服务器上这是你的责任
在 Root 服务器上,没有人会在后台自动为你更新软件包——补丁的责任完全在你自己身上。这和我们在保护 SSH 访问一文中提到的原则是一样的:root 访问权限意味着完全的控制权,但同样也意味着完全的维护义务。核心组件中的权限漏洞并不罕见,Proxmox VE 7 的身份验证漏洞就是最近的例子,攻击者甚至无需密码就能以 root 身份登录。
如何在下一次通告发布时更快应对
像这样的 CERT-Bund 通告并非个例——不久前,运营者还必须在BIND 安全漏洞曝光后检查自己的 DNS 服务器,而Virtualizor 更新被攻陷事件也表明,观望等待可能代价高昂。持续关注 CERT-Bund 的 WID 通告,并定期更新 Root 服务器上的软件源——而不是只在安装时更新一次——的人,在下一次通告发布时就已经领先一步。
花五分钟运行 rpm -q NetworkManager 并查看原始通告,算不上什么大工作量——相比于一个被忽视的权限提升漏洞在生产环境的 Root 服务器上可能造成的破坏,这点投入微不足道。
