Linux系统管理员必看：如何快速检测并修复CVE-2021-4034 Polkit提权漏洞

从PwnKit到安全基线：一次真实环境下的CVE-2021-4034应急响应全记录

那天凌晨，告警平台的蜂鸣声划破了运维中心的宁静。不是寻常的CPU尖峰，也不是磁盘空间不足，而是一条来自内部安全扫描器的“高危”警报，直指一个我们本以为早已被遗忘的名字：CVE-2021-4034，圈内人更习惯称它为“PwnKit”。作为团队里负责核心生产环境Linux系统稳定的管理员，我的第一反应是难以置信——这个2022年初曝光的Polkit提权漏洞，理论上所有主流发行版都应该在一年多前就完成了修复。但现实是，在某个承载着老旧遗留应用的CentOS 7.6服务器上，它依然“健在”。接下来的十几个小时，是一场与时间赛跑的漏洞检测、修复与验证之战。这篇文章，就是那次实战的完整复盘与深度延伸，我希望通过我的亲身经历，为你呈现一套超越简单命令执行的、面向复杂生产环境的系统化响应策略。

1. 漏洞重现：理解PwnKit为何如此危险

在急于敲入修复命令之前，我们得先弄明白对手到底是什么。CVE-2021-4034之所以被标记为“高危”，并不仅仅因为它的CVSS评分高达7.8，更在于它的普遍性、易利用性和静默性。

Polkit（原名PolicyKit）是Linux系统中一个至关重要的授权管理框架。它允许非特权用户以提升的权限执行特定命令，其核心组件 pkexec 是一个类似于 sudo 的工具，但设计上更精细，可以基于策略规则进行授权。问题就出在 pkexec 对命令行参数的处理逻辑上。

简单来说，pkexec 的底层C代码在处理参数数组 argv 时，存在一个经典的“越界读取”漏洞。当 pkexec 被调用且不带任何命令行参数时（即 argc=0），其内部逻辑会错误地尝试读取 argv[1]。在C语言中，argv[0] 通常是程序名本身，argv[1] 才是第一个真正的参数。当 argc=0 时，argv[1] 实际上指向了环境变量存储区。攻击者可以精心操控环境变量，让 pkexec 将某个环境变量误认为是可执行文件路径并加载执行，从而绕过所有策略检查，直接以root身份运行任意代码。

这带来了几个可怕的特性：

• 零交互：无需用户密码，无需任何交互式确认。
• 预装存在：pkexec 是Polkit的一部分，而Polkit在几乎所有主流桌面和服务器Linux发行版上都是默认安装的。
• 利用稳定：公开的漏洞利用代码（PoC）非常简短且可靠，几乎可以在所有受影响系统上稳定获得root shell。

为了让你更直观地理解其影响范围，我整理了当时我们内部风险评估时用到的一个简要表格：