CVE-2021-4034这个名字在安全圈里几乎与PwnKit画等号它就是Polkit组件中pkexec程序存在的一个本地权限提升漏洞。危害程度极高影响面覆盖了几乎所有主流Linux发行版。很多人在公告刚公开时都难以置信一个普通用户不需要密码不需要交互认证只要在终端里执行一条构造好的命令就能在一台默认配置的Linux系统上直接拿到root权限。这篇文章我不会直接给你一个现成的攻击脚本而是想从漏洞机制、利用原理、补丁修复、检测防御四个维度带你完整理解这个漏洞的前因后果。无论你是安全研究员、系统运维还是对Linux底层运行机制感兴趣的开发者都能从这里带走一些可以落地的东西。1. 漏洞背景与机制拆解1.1 什么是Polkit和pkexecPolkitPolicyKit是Linux系统上用于管理特权授权的一个框架它连接用户空间程序和系统服务。你可以把它理解成一道权限闸门专门回答当前用户有没有资格执行某个特权操作这个问题。举个日常例子桌面用户想挂载一块移动硬盘、修改系统时间或重启某个系统服务如果这些操作直接放开给所有普通用户系统就乱套了如果全部交给sudo又显得太过宽泛。Polkit的定位就是接管这类细粒度授权。pkexec是Polkit提供的命令行工具它和sudo在表面上有几分相似都是让普通用户以特权身份执行命令。但pkexec更强调策略控制执行时会先通过Polkit的授权机制检查用户是否有对应权限认证通过后再以root权限运行指定的目标程序。由于很多桌面环境的后台管理操作最终都会落到pkexec上几乎每个带图形界面的Linux系统都默认安装了它。即便是服务器系统只要能通过包管理器安装桌面组件或GNOME相关软件包pkexec也会被拉进来。可以说它是一个默认存在、默认可用、默认带特权限位的组件这为漏洞提供了天然的引爆条件。1.2 漏洞本质参数处理中的越界写CVE-2021-4034的根因是pkexec在解析命令行参数时出现了一次越界写。什么叫越界写简单说程序在内存里写入数据时超出了原本给它划定的区域边界。打个比方你准备了一个只能装下10张纸的信封却硬塞了11张多出来的那张纸会戳破信封落到旁边原本放其他文件的格子里。程序的世界里旁边可能恰好是另一个变量甚至是整个数组的关键字段。具体到pkexec它的main函数在遍历命令行参数时会构造一个新的参数向量供后续execve系统调用使用。问题出在构造过程中程序错误地把参数向量末尾的NULL终止符写到了数组边界之外。这个NULL指针落在哪儿恰好落在相邻的内存区域也就是环境变量指针数组所在的区域。这一写把参数数组结尾和环境变量数组开头的边界完全打乱了。后续程序在读取环境变量时就会把攻击者精心布置的指针误当成合法参数或环境变量由此打开了一条通往代码执行的通道。需要强调的是越界写本身并不罕见但这个越界写发生在setuid程序里进程已经拥有root权限所以一个看似很小的边界错误最终会放大成以root身份执行任意代码的灾难。1.3 为什么影响如此之广这个漏洞的影响范围之所以横跨几乎所有主流Linux发行版有两个直接原因。第一pkexec是setuid二进制文件。setuid位意味着普通用户执行这个文件时进程会临时获得文件属主root的权限。pkexec在设计上必须带setuid位因为它要以特权身份去调用授权机制和最终的目标命令。攻击者利用的正是这个设计触发越界写后后续所有误操作都发生在root权限进程内。第二缺陷代码在2009年前后就被引入直到2022年1月才被公开并修复。十几年间这个bug一直潜伏在Polkit代码库里。从用户角度看只要你的Linux系统装过任何依赖polkit的软件包pkexec就大概率存在而且很可能一直停留在老版本。漏洞公开后社区迅速把它评为本地提权方向的高危漏洞大量安全团队直接把它列进必须优先处理清单。原因很简单本地用户拿到root意味着攻击链的最后一公里被打通后续的横向渗透、持久化操作都畅通无阻。1.4 它是本地漏洞不是远程漏洞这里有必要把概念说清楚CVE-2021-4034是本地权限提升漏洞不是像Web漏洞那样可以直接从公网打进去的远程漏洞。远程攻击者不能直接利用它必须先拿到目标系统上的一个低权限用户执行环境比如通过Web应用漏洞拿到一个www-data权限的WebShell或者通过钓鱼获得一个普通账号。所以它在攻击链条中的角色通常是一个放大器攻击者已经攻破了第一道防线但权限很低这时执行一次PwnKit就能瞬间变成root完成后续的提权操作。理解这一点对防御很重要。如果你只防外网不防内网这类漏洞就是潜伏的定时炸弹。这也是为什么很多安全基线要求对包括pkexec在内的setuid文件进行长期监控。2. 漏洞利用原理深入2.1 从越界写到控制流劫持越界写虽然严重但并非每个越界写都能顺利变成代码执行。CVE-2021-4034之所以被视为教科书级别是因为它成功把一次NULL写入转化成了对内容完全可控的指针覆盖。在Linux的进程初始栈布局中argv指针数组和envp指针数组是连续存放的。正常情况下argv[argc]这个位置应该是一个NULL表示参数列表结束紧接着的环境变量数组才开始。pkexec的错误在于它把NULL写到了更后面的位置覆盖了环境变量数组中的某一个元素。由于环境变量的内容和顺序完全由攻击者控制攻击者通过调整环境变量就能让被覆盖的那个指针变成自己想要的值。于是后续execve执行时内核和动态加载器看到的是一个被污染的参数列表它会把这个假参数当作真实参数甚至把攻击者构造的某个环境变量当作程序路径或库加载选项来处理。为了更直观地理解我写一个简化版的C程序模拟边界算错导致越界写的行为#include stdio.h #include stdlib.h int main(int argc, char **argv) { // 错误的做法只分配了 argc 个指针没有留出结尾 NULL 的位置 char **fake_argv malloc(sizeof(char *) * argc); int i; for (i 0; i argc; i) { fake_argv[i] argv[i]; } // 这里越界了fake_argv 合法下标是 0 ~ argc-1却写入了下标 argc fake_argv[argc] NULL; printf(done\n); free(fake_argv); return 0; }这段代码里malloc只分配了能容纳argc个指针的空间但循环结束后又在fake_argv[argc]写入NULL多写了一个指针长度。用gcc编译后用valgrind检查或者在gdb里观察都会报告堆越界写。pkexec里的问题本质类似只不过发生在栈上而且这个多写的NULL正好破坏了环境变量布局。这个模拟程序只用于理解原理不是攻击代码。2.2 环境变量注入GCONV_PATH与gconv模块一个空指针如何变成代码执行关键在Linux动态加载器对环境变量的处理逻辑上。Linux程序启动时内核先加载动态链接器一般是ld.so由它负责加载共享库、完成符号重定位然后把控制权交给程序的入口函数。动态加载器会读取一批环境变量其中很多特权变量在setuid程序里会被过滤掉。最典型的例子是LD_PRELOAD它允许用户预加载任意共享库但如果setuid程序还允许它生效那任何普通用户都能轻松提权所以glibc对此做了隔离处理。但并非所有环境变量都享受同等级别的安全审查。GCONV_PATH就是其中之一。这个变量是glibc的字符集转换iconv功能使用的用来指定额外的gconv模块搜索路径。当程序需要进行字符集转换时会按GCONV_PATH去对应目录查找一个名为gconv-modules的描述文件再根据描述加载共享库。由于GCONV_PATH的初衷是让管理员可以扩展系统中的字符集支持它本质上允许一个普通进程去指定加载路径下的库对setuid进程来说这就是一个危险的攻击面。CVE-2021-4034的越界写正好让pkexec在调用execve时没有正确清理GCONV_PATH这类环境变量。攻击者在本地构造一个目录放上恶意共享库和gconv-modules描述文件再把GCONV_PATH指向该目录当pkexec以root身份触发动态加载流程时glibc就会沿着攻击者指定的路径去加载一个外部模块。这个模块的构造函数会在加载瞬间自动执行执行时进程已经是root权限代码执行就此完成。整个过程完全绕过了传统setuid程序的自我保护机制。2.3 一条完整的利用链把前面几块拼起来PwnKit的利用链条其实非常清晰攻击者先获得目标系统上的本地低权限执行环境比如一个普通用户Shell。在可写的目录下创建恶意gconv模块即一个精心编译的共享库同时编写配套的gconv-modules描述文件。通过环境变量GCONV_PATH指向该目录并设置必要的CHARSET等变量确保动态加载器会去解析这个路径。以普通用户身份执行pkexec不带参数或使用特定参数组合触发参数向量越界写。越界写导致pkexec进程以root权限继续执行错误地把环境变量数据透传给动态加载器。动态加载器读取GCONV_PATH加载恶意gconv模块模块构造函数以root身份执行攻击者预设命令。攻击者获得root shell。整个利用过程没有密码、没有交互、没有额外内核依赖。公开POC的体积非常小攻击者可以本地编译后瞬间执行。这也是为什么很多攻防演习中PwnKit会被当作首选提权手段之一。理解这条链不是为了复刻攻击而是为了更清楚地知道应该在哪里设防。2.4 与其他提权漏洞的横向对比不妨把它和同样是本地提权的sudo漏洞做一个对比方便你建立防御优先级。sudo的CVE-2021-3156Baron Samedit也是一个越界写漏洞但触发条件相对苛刻需要特定的sudo版本还需要通过sudoedit -s这样的路径触发。而CVE-2021-4034不依赖sudo不依赖特定配置只要系统里存在默认安装的pkexec就大概率命中。从稳定性看PwnKit在多架构、多发行版上都被验证为高度可靠。从防御角度看这两个高危漏洞都指向同一个问题setuid程序在边界处理和环境变量处理上存在系统性信任缺失。我们在做安全建设时不能只针对某个具体CVE打补丁而应该建立对setuid程序清单、环境变量策略的动态审查机制。3. 实操过程与核心环节实现3.1 实验环境准备如果希望亲手研究这个漏洞我强烈建议使用完全隔离的虚拟机不要在主用的工作电脑或任何生产环境里尝试。一个典型的实验环境长这样选择一个2022年1月之前发布的Linux发行版镜像或者直接用包含旧polkit的容器镜像。创建普通权限的测试用户确保后续以非root身份执行操作。保存一个干净的虚拟机快照方便随时回滚到初始状态。在容器里模拟时需要额外注意很多精简容器镜像默认没有安装polkit需要先用包管理器安装。比如先执行类似apt install policykit-1的操作把pkexec准备出来。容器中的默认用户如果权限过高需要用su testuser切换到低权限用户否则测试环境不真实无法体现漏洞的从普通用户提权过程。在隔离环境里还要确认一下能不能使用编译器。如果镜像里没有gcc需要先安装构建工具因为研究过程中可能要编译验证用的小工具。3.2 检查pkexec是否处于受影响状态在接触任何POC之前先做几个无害检查判断系统是否处于受影响状态。第一步查看pkexec版本pkexec --version第二步查看文件权限ls -l /usr/bin/pkexec正常的pkexec应当属于root并且权限中有s位例如-rwsr-xr-x。如果setuid位已经手动去掉则漏洞利用的必要条件之一已经不存在。第三步核对补丁状态。最直接的方法是查发行版安全公告然后把当前系统里pkexec的实际版本号与修复版本做对比。不同发行版的版本号策略不同这里不逐一举例但原则是只要版本低于修复版本就视为存在风险。这里有必要说明我不会在文章中提供可用的POC代码或完整利用脚本。安全研究的价值在于理解和防御而不是扩散攻击能力。如果你只是想知道系统是否仍然存在漏洞很多发行版的安全团队已经提供了轻量级检测脚本只做无害探测不执行提权动作。3.3 理解补丁到底改了什么理解补丁内容比背住CVE编号更有意义。CVE-2021-4034的修复补丁主要做了两件事。第一修正参数向量的分配与填充逻辑。原来的代码在构造新参数向量时对长度计算出现了偏差导致末尾的NULL写到界外。补丁将长度计算改为基于实际参数个数argc并确保分配时额外留出空指针的位置让数组始终是完整的“参数区 NULL结束符”结构。从代码层面看这就是一次典型的“分配长度少算1”修复。第二收紧环境变量信任。由于整个利用链依赖动态加载器读取GCONV_PATH补丁在pkexec运行过程中加强了对环境变量的清洗与控制。部分发行版同步更新了glibc让setuid进程默认忽略GCONV_PATH指定的外部模块路径。也就是说即便将来再有参数解析类漏洞攻击者也不能简单地通过GCONV_PATH来完成代码执行。这种“修复两个点”的思路值得学习。第一个点解决内存越界第二个点削减攻击原语。安全修复不能只堵当前这一条利用路径还要削弱同类攻击的基础。3.4 验证修复效果升级polkit包之后重新执行pkexec --version确认版本号已经变化。如果原来保存了二进制文件的哈希值可以对比升级前后是否不同sha256sum /usr/bin/pkexec升级前和升级后的输出应当明显不同。更进一步的验证可以再次运行无害检测脚本修复后的系统应当无法触发漏洞。对运维团队而言我建议把pkexec版本检测纳入安全基线模板在所有主机上定时核对。补丁滞后在内网是非常普通的现状而攻击者利用自动化工具扫描到漏洞后从探测到提权可能只需要几秒钟。如果等出了问题再去排查代价会大得多。4. 常见问题与排查技巧实录4.1 打补丁后pkexec突然无法工作升级polkit之后有一部分同学会发现桌面环境中的管理操作异常比如点击“挂载磁盘”或“修改系统时间”时提示授权失败。这种情况通常不是补丁本身出错而是polkit新版本调整了授权规则的行为逻辑或者系统内自定义规则没有跟上新API的变更。可以检查/usr/share/polkit-1/actions/下的动作定义以及/etc/polkit-1/rules.d/下的自定义规则。如果规则里用到了旧版JavaScript API需要按新版本文档调整。另外检查polkit服务是否正常systemctl status polkit服务状态异常时很多授权操作也会一并失效。4.2 系统里找不到pkexec怎么办有些精简服务器或最小化容器镜像并没有安装polkit自然也没有pkexec。对这类系统CVE-2021-4034本身不适用但要分两种情况看待如果系统后续会因为安装桌面组件或依赖软件而引入polkit那就要确保安装时直接带上最新版本如果系统业务本身完全不需要polkit可以考虑在软件包层面彻底锁定防止未来依赖关系把它拉进来。另外部分发行版即使没有pkexec也可能存在polkit-agent-helper-1等配套组件它们同样属于polkit家族需要一并检查安全更新。4.3 如何排查系统中是否出现PwnKit攻击痕迹如果担心系统已经被利用过可以从几个方向排查。第一检查临时目录下是否存在可疑的gconv相关文件。攻击者通常会在可写目录里创建恶意动态库和gconv-modules描述文件比如在/tmp下建一个看起来不起眼的目录里面放着.so文件和描述文件。如果发现非系统标准路径下的gconv模块需要重点排查。第二查看审计日志中pkexec的执行记录。在开启auditd的环境下可以这样搜索ausearch -m EXECVE -c pkexec重点关注低权限用户发起的pkexec调用特别是参数和环境变量异常的情况。攻击者触发PwnKit时pkexec进程的命令行往往非常简单但进程环境里可能带着GCONV_PATH等特殊变量。第三检查历史命令痕迹。攻击者为了编译恶意模块通常会在受影响用户目录下留下gcc -shared -fPIC等命令的痕迹。排查/root/.bash_history和普通用户目录下的历史文件可以发现蛛丝马迹。第四检查持久化项。如果攻击者利用root权限做了后续持久化会在定时任务、自启动目录、服务文件里留下痕迹。使用systemctl list-unit-files | grep enabled和crontab -l做一轮例行检查能提高发现概率。4.4 临时缓解后如何恢复应急时最常用的临时缓解措施是去掉pkexec的setuid位chmod 0755 /usr/bin/pkexec这样pkexec不再以root权限运行漏洞利用的关键条件被破坏。但代价是系统里所有依赖pkexec的授权操作都会失效所以这只是应急手段不能作为长期方案。完成升级后要记得恢复权限位chmod 4755 /usr/bin/pkexec恢复后再次用ls -l确认权限是-rwsr-xr-x。我见过有同事在应急期间同时改了一大批setuid程序事后忘了恢复导致系统上所有特权授权操作静默失败排查了很久才发现是权限位不对。临时缓解一定要记录变更修复后逐项回滚。5. 实操心得与后续扩展建议5.1 实验后的恢复与常见坑位自己做实验时有几个坑非常典型值得单独提一下。第一个坑是在“看似隔离”的容器里直接测试漏洞。容器与宿主机共享内核虽然一般不能直接影响宿主机但如果容器以特权模式运行或者把宿主机目录挂载进容器隔离性就会大打折扣。建议使用虚拟机并且不要在VM中挂载宿主机目录。第二个坑是升级后没有重启相关服务。部分老版本系统在升级polkit后旧的pkexec进程可能还驻留在内存中需要重启polkit服务甚至重启系统才能让新版本完全生效。确认二进制已更新后再安排维护窗口。第三个坑是只替换pkexec一个二进制而没有升级整个polkit包。同一个包里往往还有polkit-agent-helper-1、授权规则库等多个组件它们也可能存在配套安全更新。单独替换会造成版本碎片化后续安全维护更难做。第四个坑是基线检查脚本只判断pkexec文件是否存在。存在但版本老旧依然有风险不存在但有polkit其他组件也有潜在问题。正确的做法是结合版本号判断当前系统是否处于受影响范围而不是只看文件存不存在。5.2 从PwnKit延伸出的安全思考PwnKit之所以影响面如此之大是因为它把setuid、参数解析、环境变量、动态加载器这几个老问题组合在了一起。这提醒我在做安全研发或系统加固时不能只盯着CVSS分数而要关注漏洞背后的通用模式。如果你有代码审计能力可以写一个静态分析规则专门检测“分配argv长度时漏掉结尾NULL”这类边界错误。这类规则不仅在pkexec身上有效对很多类似的setuid工具也适用。在日常巡检里可以建立一套setuid程序清单定期检查这些文件的权限位、属主、版本和补丁状态。同时对环境中是否有人手动修改过GCONV_PATH这类变量保持敏感。预防和检测一个漏洞最长期有效的方法不是记住CVE编号而是理解它背后的信任边界问题。PwnKit已经过去很久但它留下的功课值得在每次安全加固时反复拿出来对照。 
长河君 · 2026/10/21 17:42:12 · 阅读 1.2k CVE-2021-4034（PwnKit）漏洞剖析：Polkit pkexec本地提权机制与防御
CVE-2021-4034这个名字在安全圈里几乎与PwnKit画等号它就是Polkit组件中pkexec程序存在的一个本地权限提升漏洞。危害程度极高影响面覆盖了几乎所有主流Linux发行版。很多人在公告刚公开时都难以置信一个普通用户不需要密码不需要交互认证只要在终端里执行一条构造好的命令就能在一台默认配置的Linux系统上直接拿到root权限。这篇文章我不会直接给你一个现成的攻击脚本而是想从漏洞机制、利用原理、补丁修复、检测防御四个维度带你完整理解这个漏洞的前因后果。无论你是安全研究员、系统运维还是对Linux底层运行机制感兴趣的开发者都能从这里带走一些可以落地的东西。1. 漏洞背景与机制拆解1.1 什么是Polkit和pkexecPolkitPolicyKit是Linux系统上用于管理特权授权的一个框架它连接用户空间程序和系统服务。你可以把它理解成一道权限闸门专门回答当前用户有没有资格执行某个特权操作这个问题。举个日常例子桌面用户想挂载一块移动硬盘、修改系统时间或重启某个系统服务如果这些操作直接放开给所有普通用户系统就乱套了如果全部交给sudo又显得太过宽泛。Polkit的定位就是接管这类细粒度授权。pkexec是Polkit提供的命令行工具它和sudo在表面上有几分相似都是让普通用户以特权身份执行命令。但pkexec更强调策略控制执行时会先通过Polkit的授权机制检查用户是否有对应权限认证通过后再以root权限运行指定的目标程序。由于很多桌面环境的后台管理操作最终都会落到pkexec上几乎每个带图形界面的Linux系统都默认安装了它。即便是服务器系统只要能通过包管理器安装桌面组件或GNOME相关软件包pkexec也会被拉进来。可以说它是一个默认存在、默认可用、默认带特权限位的组件这为漏洞提供了天然的引爆条件。1.2 漏洞本质参数处理中的越界写CVE-2021-4034的根因是pkexec在解析命令行参数时出现了一次越界写。什么叫越界写简单说程序在内存里写入数据时超出了原本给它划定的区域边界。打个比方你准备了一个只能装下10张纸的信封却硬塞了11张多出来的那张纸会戳破信封落到旁边原本放其他文件的格子里。程序的世界里旁边可能恰好是另一个变量甚至是整个数组的关键字段。具体到pkexec它的main函数在遍历命令行参数时会构造一个新的参数向量供后续execve系统调用使用。问题出在构造过程中程序错误地把参数向量末尾的NULL终止符写到了数组边界之外。这个NULL指针落在哪儿恰好落在相邻的内存区域也就是环境变量指针数组所在的区域。这一写把参数数组结尾和环境变量数组开头的边界完全打乱了。后续程序在读取环境变量时就会把攻击者精心布置的指针误当成合法参数或环境变量由此打开了一条通往代码执行的通道。需要强调的是越界写本身并不罕见但这个越界写发生在setuid程序里进程已经拥有root权限所以一个看似很小的边界错误最终会放大成以root身份执行任意代码的灾难。1.3 为什么影响如此之广这个漏洞的影响范围之所以横跨几乎所有主流Linux发行版有两个直接原因。第一pkexec是setuid二进制文件。setuid位意味着普通用户执行这个文件时进程会临时获得文件属主root的权限。pkexec在设计上必须带setuid位因为它要以特权身份去调用授权机制和最终的目标命令。攻击者利用的正是这个设计触发越界写后后续所有误操作都发生在root权限进程内。第二缺陷代码在2009年前后就被引入直到2022年1月才被公开并修复。十几年间这个bug一直潜伏在Polkit代码库里。从用户角度看只要你的Linux系统装过任何依赖polkit的软件包pkexec就大概率存在而且很可能一直停留在老版本。漏洞公开后社区迅速把它评为本地提权方向的高危漏洞大量安全团队直接把它列进必须优先处理清单。原因很简单本地用户拿到root意味着攻击链的最后一公里被打通后续的横向渗透、持久化操作都畅通无阻。1.4 它是本地漏洞不是远程漏洞这里有必要把概念说清楚CVE-2021-4034是本地权限提升漏洞不是像Web漏洞那样可以直接从公网打进去的远程漏洞。远程攻击者不能直接利用它必须先拿到目标系统上的一个低权限用户执行环境比如通过Web应用漏洞拿到一个www-data权限的WebShell或者通过钓鱼获得一个普通账号。所以它在攻击链条中的角色通常是一个放大器攻击者已经攻破了第一道防线但权限很低这时执行一次PwnKit就能瞬间变成root完成后续的提权操作。理解这一点对防御很重要。如果你只防外网不防内网这类漏洞就是潜伏的定时炸弹。这也是为什么很多安全基线要求对包括pkexec在内的setuid文件进行长期监控。2. 漏洞利用原理深入2.1 从越界写到控制流劫持越界写虽然严重但并非每个越界写都能顺利变成代码执行。CVE-2021-4034之所以被视为教科书级别是因为它成功把一次NULL写入转化成了对内容完全可控的指针覆盖。在Linux的进程初始栈布局中argv指针数组和envp指针数组是连续存放的。正常情况下argv[argc]这个位置应该是一个NULL表示参数列表结束紧接着的环境变量数组才开始。pkexec的错误在于它把NULL写到了更后面的位置覆盖了环境变量数组中的某一个元素。由于环境变量的内容和顺序完全由攻击者控制攻击者通过调整环境变量就能让被覆盖的那个指针变成自己想要的值。于是后续execve执行时内核和动态加载器看到的是一个被污染的参数列表它会把这个假参数当作真实参数甚至把攻击者构造的某个环境变量当作程序路径或库加载选项来处理。为了更直观地理解我写一个简化版的C程序模拟边界算错导致越界写的行为#include stdio.h #include stdlib.h int main(int argc, char **argv) { // 错误的做法只分配了 argc 个指针没有留出结尾 NULL 的位置 char **fake_argv malloc(sizeof(char *) * argc); int i; for (i 0; i argc; i) { fake_argv[i] argv[i]; } // 这里越界了fake_argv 合法下标是 0 ~ argc-1却写入了下标 argc fake_argv[argc] NULL; printf(done\n); free(fake_argv); return 0; }这段代码里malloc只分配了能容纳argc个指针的空间但循环结束后又在fake_argv[argc]写入NULL多写了一个指针长度。用gcc编译后用valgrind检查或者在gdb里观察都会报告堆越界写。pkexec里的问题本质类似只不过发生在栈上而且这个多写的NULL正好破坏了环境变量布局。这个模拟程序只用于理解原理不是攻击代码。2.2 环境变量注入GCONV_PATH与gconv模块一个空指针如何变成代码执行关键在Linux动态加载器对环境变量的处理逻辑上。Linux程序启动时内核先加载动态链接器一般是ld.so由它负责加载共享库、完成符号重定位然后把控制权交给程序的入口函数。动态加载器会读取一批环境变量其中很多特权变量在setuid程序里会被过滤掉。最典型的例子是LD_PRELOAD它允许用户预加载任意共享库但如果setuid程序还允许它生效那任何普通用户都能轻松提权所以glibc对此做了隔离处理。但并非所有环境变量都享受同等级别的安全审查。GCONV_PATH就是其中之一。这个变量是glibc的字符集转换iconv功能使用的用来指定额外的gconv模块搜索路径。当程序需要进行字符集转换时会按GCONV_PATH去对应目录查找一个名为gconv-modules的描述文件再根据描述加载共享库。由于GCONV_PATH的初衷是让管理员可以扩展系统中的字符集支持它本质上允许一个普通进程去指定加载路径下的库对setuid进程来说这就是一个危险的攻击面。CVE-2021-4034的越界写正好让pkexec在调用execve时没有正确清理GCONV_PATH这类环境变量。攻击者在本地构造一个目录放上恶意共享库和gconv-modules描述文件再把GCONV_PATH指向该目录当pkexec以root身份触发动态加载流程时glibc就会沿着攻击者指定的路径去加载一个外部模块。这个模块的构造函数会在加载瞬间自动执行执行时进程已经是root权限代码执行就此完成。整个过程完全绕过了传统setuid程序的自我保护机制。2.3 一条完整的利用链把前面几块拼起来PwnKit的利用链条其实非常清晰攻击者先获得目标系统上的本地低权限执行环境比如一个普通用户Shell。在可写的目录下创建恶意gconv模块即一个精心编译的共享库同时编写配套的gconv-modules描述文件。通过环境变量GCONV_PATH指向该目录并设置必要的CHARSET等变量确保动态加载器会去解析这个路径。以普通用户身份执行pkexec不带参数或使用特定参数组合触发参数向量越界写。越界写导致pkexec进程以root权限继续执行错误地把环境变量数据透传给动态加载器。动态加载器读取GCONV_PATH加载恶意gconv模块模块构造函数以root身份执行攻击者预设命令。攻击者获得root shell。整个利用过程没有密码、没有交互、没有额外内核依赖。公开POC的体积非常小攻击者可以本地编译后瞬间执行。这也是为什么很多攻防演习中PwnKit会被当作首选提权手段之一。理解这条链不是为了复刻攻击而是为了更清楚地知道应该在哪里设防。2.4 与其他提权漏洞的横向对比不妨把它和同样是本地提权的sudo漏洞做一个对比方便你建立防御优先级。sudo的CVE-2021-3156Baron Samedit也是一个越界写漏洞但触发条件相对苛刻需要特定的sudo版本还需要通过sudoedit -s这样的路径触发。而CVE-2021-4034不依赖sudo不依赖特定配置只要系统里存在默认安装的pkexec就大概率命中。从稳定性看PwnKit在多架构、多发行版上都被验证为高度可靠。从防御角度看这两个高危漏洞都指向同一个问题setuid程序在边界处理和环境变量处理上存在系统性信任缺失。我们在做安全建设时不能只针对某个具体CVE打补丁而应该建立对setuid程序清单、环境变量策略的动态审查机制。3. 实操过程与核心环节实现3.1 实验环境准备如果希望亲手研究这个漏洞我强烈建议使用完全隔离的虚拟机不要在主用的工作电脑或任何生产环境里尝试。一个典型的实验环境长这样选择一个2022年1月之前发布的Linux发行版镜像或者直接用包含旧polkit的容器镜像。创建普通权限的测试用户确保后续以非root身份执行操作。保存一个干净的虚拟机快照方便随时回滚到初始状态。在容器里模拟时需要额外注意很多精简容器镜像默认没有安装polkit需要先用包管理器安装。比如先执行类似apt install policykit-1的操作把pkexec准备出来。容器中的默认用户如果权限过高需要用su testuser切换到低权限用户否则测试环境不真实无法体现漏洞的从普通用户提权过程。在隔离环境里还要确认一下能不能使用编译器。如果镜像里没有gcc需要先安装构建工具因为研究过程中可能要编译验证用的小工具。3.2 检查pkexec是否处于受影响状态在接触任何POC之前先做几个无害检查判断系统是否处于受影响状态。第一步查看pkexec版本pkexec --version第二步查看文件权限ls -l /usr/bin/pkexec正常的pkexec应当属于root并且权限中有s位例如-rwsr-xr-x。如果setuid位已经手动去掉则漏洞利用的必要条件之一已经不存在。第三步核对补丁状态。最直接的方法是查发行版安全公告然后把当前系统里pkexec的实际版本号与修复版本做对比。不同发行版的版本号策略不同这里不逐一举例但原则是只要版本低于修复版本就视为存在风险。这里有必要说明我不会在文章中提供可用的POC代码或完整利用脚本。安全研究的价值在于理解和防御而不是扩散攻击能力。如果你只是想知道系统是否仍然存在漏洞很多发行版的安全团队已经提供了轻量级检测脚本只做无害探测不执行提权动作。3.3 理解补丁到底改了什么理解补丁内容比背住CVE编号更有意义。CVE-2021-4034的修复补丁主要做了两件事。第一修正参数向量的分配与填充逻辑。原来的代码在构造新参数向量时对长度计算出现了偏差导致末尾的NULL写到界外。补丁将长度计算改为基于实际参数个数argc并确保分配时额外留出空指针的位置让数组始终是完整的“参数区 NULL结束符”结构。从代码层面看这就是一次典型的“分配长度少算1”修复。第二收紧环境变量信任。由于整个利用链依赖动态加载器读取GCONV_PATH补丁在pkexec运行过程中加强了对环境变量的清洗与控制。部分发行版同步更新了glibc让setuid进程默认忽略GCONV_PATH指定的外部模块路径。也就是说即便将来再有参数解析类漏洞攻击者也不能简单地通过GCONV_PATH来完成代码执行。这种“修复两个点”的思路值得学习。第一个点解决内存越界第二个点削减攻击原语。安全修复不能只堵当前这一条利用路径还要削弱同类攻击的基础。3.4 验证修复效果升级polkit包之后重新执行pkexec --version确认版本号已经变化。如果原来保存了二进制文件的哈希值可以对比升级前后是否不同sha256sum /usr/bin/pkexec升级前和升级后的输出应当明显不同。更进一步的验证可以再次运行无害检测脚本修复后的系统应当无法触发漏洞。对运维团队而言我建议把pkexec版本检测纳入安全基线模板在所有主机上定时核对。补丁滞后在内网是非常普通的现状而攻击者利用自动化工具扫描到漏洞后从探测到提权可能只需要几秒钟。如果等出了问题再去排查代价会大得多。4. 常见问题与排查技巧实录4.1 打补丁后pkexec突然无法工作升级polkit之后有一部分同学会发现桌面环境中的管理操作异常比如点击“挂载磁盘”或“修改系统时间”时提示授权失败。这种情况通常不是补丁本身出错而是polkit新版本调整了授权规则的行为逻辑或者系统内自定义规则没有跟上新API的变更。可以检查/usr/share/polkit-1/actions/下的动作定义以及/etc/polkit-1/rules.d/下的自定义规则。如果规则里用到了旧版JavaScript API需要按新版本文档调整。另外检查polkit服务是否正常systemctl status polkit服务状态异常时很多授权操作也会一并失效。4.2 系统里找不到pkexec怎么办有些精简服务器或最小化容器镜像并没有安装polkit自然也没有pkexec。对这类系统CVE-2021-4034本身不适用但要分两种情况看待如果系统后续会因为安装桌面组件或依赖软件而引入polkit那就要确保安装时直接带上最新版本如果系统业务本身完全不需要polkit可以考虑在软件包层面彻底锁定防止未来依赖关系把它拉进来。另外部分发行版即使没有pkexec也可能存在polkit-agent-helper-1等配套组件它们同样属于polkit家族需要一并检查安全更新。4.3 如何排查系统中是否出现PwnKit攻击痕迹如果担心系统已经被利用过可以从几个方向排查。第一检查临时目录下是否存在可疑的gconv相关文件。攻击者通常会在可写目录里创建恶意动态库和gconv-modules描述文件比如在/tmp下建一个看起来不起眼的目录里面放着.so文件和描述文件。如果发现非系统标准路径下的gconv模块需要重点排查。第二查看审计日志中pkexec的执行记录。在开启auditd的环境下可以这样搜索ausearch -m EXECVE -c pkexec重点关注低权限用户发起的pkexec调用特别是参数和环境变量异常的情况。攻击者触发PwnKit时pkexec进程的命令行往往非常简单但进程环境里可能带着GCONV_PATH等特殊变量。第三检查历史命令痕迹。攻击者为了编译恶意模块通常会在受影响用户目录下留下gcc -shared -fPIC等命令的痕迹。排查/root/.bash_history和普通用户目录下的历史文件可以发现蛛丝马迹。第四检查持久化项。如果攻击者利用root权限做了后续持久化会在定时任务、自启动目录、服务文件里留下痕迹。使用systemctl list-unit-files | grep enabled和crontab -l做一轮例行检查能提高发现概率。4.4 临时缓解后如何恢复应急时最常用的临时缓解措施是去掉pkexec的setuid位chmod 0755 /usr/bin/pkexec这样pkexec不再以root权限运行漏洞利用的关键条件被破坏。但代价是系统里所有依赖pkexec的授权操作都会失效所以这只是应急手段不能作为长期方案。完成升级后要记得恢复权限位chmod 4755 /usr/bin/pkexec恢复后再次用ls -l确认权限是-rwsr-xr-x。我见过有同事在应急期间同时改了一大批setuid程序事后忘了恢复导致系统上所有特权授权操作静默失败排查了很久才发现是权限位不对。临时缓解一定要记录变更修复后逐项回滚。5. 实操心得与后续扩展建议5.1 实验后的恢复与常见坑位自己做实验时有几个坑非常典型值得单独提一下。第一个坑是在“看似隔离”的容器里直接测试漏洞。容器与宿主机共享内核虽然一般不能直接影响宿主机但如果容器以特权模式运行或者把宿主机目录挂载进容器隔离性就会大打折扣。建议使用虚拟机并且不要在VM中挂载宿主机目录。第二个坑是升级后没有重启相关服务。部分老版本系统在升级polkit后旧的pkexec进程可能还驻留在内存中需要重启polkit服务甚至重启系统才能让新版本完全生效。确认二进制已更新后再安排维护窗口。第三个坑是只替换pkexec一个二进制而没有升级整个polkit包。同一个包里往往还有polkit-agent-helper-1、授权规则库等多个组件它们也可能存在配套安全更新。单独替换会造成版本碎片化后续安全维护更难做。第四个坑是基线检查脚本只判断pkexec文件是否存在。存在但版本老旧依然有风险不存在但有polkit其他组件也有潜在问题。正确的做法是结合版本号判断当前系统是否处于受影响范围而不是只看文件存不存在。5.2 从PwnKit延伸出的安全思考PwnKit之所以影响面如此之大是因为它把setuid、参数解析、环境变量、动态加载器这几个老问题组合在了一起。这提醒我在做安全研发或系统加固时不能只盯着CVSS分数而要关注漏洞背后的通用模式。如果你有代码审计能力可以写一个静态分析规则专门检测“分配argv长度时漏掉结尾NULL”这类边界错误。这类规则不仅在pkexec身上有效对很多类似的setuid工具也适用。在日常巡检里可以建立一套setuid程序清单定期检查这些文件的权限位、属主、版本和补丁状态。同时对环境中是否有人手动修改过GCONV_PATH这类变量保持敏感。预防和检测一个漏洞最长期有效的方法不是记住CVE编号而是理解它背后的信任边界问题。PwnKit已经过去很久但它留下的功课值得在每次安全加固时反复拿出来对照。