做代码审计这些年我经手过不少“看起来不复杂”的远程代码执行漏洞但每次遇到电子签章系统里的RCE还是会格外谨慎。一方面是因为这类系统直接和合同、印章、司法效力挂钩一旦被攻破影响的是整个信任链另一方面这类系统的PDF校验组件往往是从开源项目二改或闭源封装的产物历史包袱重、输入面大。今天要聊的这次审计目标就是一个电子签章系统里的 pdfverifier 组件对应漏洞编号 QVD-2025-27432。我会把从目标画像、代码审计、根因分析到修复加固的完整思路整理出来希望能给正在做代码审计或安全研发的朋友一些参考。这次审计的核心不是“一锤子买卖”而是想借这个漏洞讲清楚一件事白盒代码审计到底怎么从零开始把一个看似无关紧要的PDF校验模块变成高危RCE入口再一步步封堵回去。这套方法论不局限于某个具体产品放在任何具备文件上传、PDF解析、签名验证能力的系统上都适用。1. 目标画像为什么 pdfverifier 是RCE审计的重灾区1.1 pdfverifier 在电子签章系统里的定位电子签章系统的核心业务链路很清晰用户上传合同文件系统对文件做签名校验和验真确认无误后写入时间戳生成具有法律效力的电子凭证。在这个过程中pdfverifier 承担的是“验真”这一步它要解析PDF内部结构提取签名域、证书信息、摘要值和原始文件做比对。听起来就是一个工具模块好像不太容易出问题。但恰恰是这个“看起来不太容易出问题”的模块每年都在漏洞报告里占据了不小比例。原因有三点输入完全不可控pdfverifier 接收的是用户上传的任意PDF文件攻击者对文件内容有百分之百的控制权。解析逻辑复杂PDF 格式本身非常灵活允许嵌入对象、字体、JavaScript、外部实体引用等解析器稍有不慎就会踩进逻辑黑洞。历史包袱重很多系统为了赶工直接调用外部命令行工具完成解析和校验Java层只负责组装命令和接收输出这就给命令注入留下了巨大空间。换句话说pdfverifier 就像一个机场安检口每天要过无数外部来的包裹如果安检仪本身有缺陷攻击者就能把“危险品”包装成普通行李混进去而安检仪还给它盖上了“通过”的章。1.2 远程代码执行一旦发生损失有多大远程代码执行RCE是漏洞界的“王炸”。它意味着攻击者不是简单地绕过某个业务规则而是直接在服务器上执行任意系统命令。放到电子签章系统的场景里后果是叠加放大的第一层是认证和凭证类数据泄露。电子签章系统存储着大量企业公章图片、个人签名样本、证书私钥、合同原文。拿到服务器权限后这些东西就是案板上的肉。第二层是业务信任链被伪造。攻击者可以利用系统本身的签名能力伪造出一份“真实有效”的电子签章文件带来法律纠纷和商务欺诈风险。第三层是横向渗透。这类系统通常部署在内网核心区和OA、ERP、数据库有网络互通。一旦拿下它内网漫游只是时间问题。QVD-2025-27432 这个编号被公开收录说明它已经不是某个小众系统里的偶发问题而是影响面广泛、已进入公共情报库的已知风险。对于还没修复的系统而言攻击者可能已经在用公开的利用方法进行批量探测了。1.3 审计前的威胁建模和攻击面梳理在动手看代码之前先别急着在编辑器里疯狂搜索“exec”。我习惯先做一轮威胁建模把可能的攻击面画出来。针对目标系统我梳理出的关键资产包括用户上传接口、PDF文件存储路径、pdfverifier组件的输入输出、日志系统、后台管理接口。信任边界是这样划分的互联网侧是低信任区上传的PDF文件是“不可信代码”系统内部服务间调用是中信任区最终执行命令或操作文件系统的进程是高权限区。攻击面的优先级排下来文件上传接口攻击者唯一能投递恶意输入的位置。文件名和文件路径如果系统用原始文件名拼接路径就可能产生路径穿越或命令注入。PDF内容字段包括文件名、文件头、元数据、字体名、注释内容等这些字段如果被拼接到内部命令或表达式里都可能成为注入点。外部命令调用边界pdfverifier 如果依赖外部程序那外部程序的参数就是最需要盯住的汇聚点。威胁建模做完我心里就有了一张“地图”接下来所有代码分析都围绕这些点展开。2. 从路由到数据流我如何快速定位 pdfverifier2.1 先看依赖和目录把组件从代码堆里捞出来拿到代码包后我一般不会先从Controller层看起而是先看项目依赖清单比如Java项目的pom.xml、Go项目的go.mod、前端项目的package.json。目标系统是Java技术栈在pom.xml里能明显看到它对PDF解析类库的依赖同时还有一个自定义的本地模块叫 pdfverifier。顺着依赖关系我找到了它对应的目录结构。这个模块不算大核心类大概十来个主要职责是加载PDF、抽取签名对象、校验证书链。但是注意模块里有一个不起眼的“外部工具调用”包里面封装了不少和本机命令交互的逻辑。看到这类包我的敏感度会立刻拉满解析PDF为什么需要调用外部命令调用的命令是什么参数从哪来为了快速定位入口我用全局搜索翻了一遍路由注解重点关注包含upload、verify、signature、pdf关键词的接口。最终在一个负责“验真回调”的Controller里找到了对pdfverifier模块的调用链。2.2 顺着上传接口追踪文件流向定位到入口之后我开始追踪一条完整的请求链路。假设某个验真接口接收到一个PDF文件处理流程大致是接收上传文件保存到临时目录。从请求参数或文件名中提取“文件原始名称”。调用 pdfverifier 的 verify 方法把文件路径传入。pdfverifier 在内部把文件路径再传递给一个外部命令由外部程序完成核心解析。返回校验结果给上层。这条链路里真正危险的是第二步到第四步的衔接。如果文件名在传递过程中没有被“中性化”而是直接进入了命令字符串那问题就大了。我重点盯了文件名相关的所有赋值语句包括上传时的原始文件名获取、文件路径的拼接、参数对象的字段传递。代码里这三层都有操作但每一层都没有看到对文件名做白名单校验或转义处理。2.3 污点分析把“可控输入”和“危险函数”连起来“污点分析”听起来很高深其实核心就一句话从不可信输入出发看它能不能一路流到敏感操作点。手工做污点分析时我会分两步走。第一步是找“源”也就是攻击者可控的数据。在这个系统里最明显的源就是HTTP请求里的文件流和文件名字段还有文件内部可以被解析器读取的内容。第二步是找“汇聚点”也就是会发生危险操作的位置系统命令执行、文件删除、数据库查询、反射调用、反序列化。我把两者放在心里然后开始逐行读代码。静态分析工具能辅助我画出数据流图但工具往往会漏掉跨方法、跨对象的隐式传递所以我仍然会人工核对每一步。最终我在 pdfverifier 的一个名为runCommand的私有方法里看到了那个“不能再典型”的危险模式。参数从文件名来方法内部拼了一条命令字符串然后用Runtime.getRuntime().exec()去执行。源头可控汇聚点危险路径上还没有任何过滤——漏洞嫌疑成立。3. 漏洞核心一次PDF校验引发的系统命令拼接3.1 危险代码长什么样下面这段代码是我脱敏后还原出的核心片段和实际漏洞代码的形态非常接近public String verify(String fileName) throws IOException { String tmpDir /tmp/uploads/; String targetPath tmpDir fileName; String command pdfverify --file targetPath; Process process Runtime.getRuntime().exec(command); // 读取命令输出返回解析结果 return readOutput(process.getInputStream()); }问题体现在最后一行命令拼接上command字符串把“文件名”直接拼到了系统命令里而且底层用的是Runtime.exec()。这种方式会触发操作系统的shell去解释整条字符串。如果把文件名构造为a.pdf; 某条命令那么分号后面的内容会被当成新的系统命令执行。有人可能会问文件名不是用户上传时指定的吗确实是。上传接口没有对原始文件名做任何限制它在多个类之间传递时都保留原始形态。也就是说攻击者只要构造一个特殊命名的PDF文件文件名本身就是恶意输入。这类漏洞在文件上传功能里非常经典但因为触发路径埋在pdfverifier里单看上传接口反而容易被忽略。3.2 为什么这里会存在远程代码执行这个漏洞的直接原因是命令字符串拼接但更深层的原因要追溯到设计选择上。目标系统的PDF解析工作没有全部用Java实现而是沿用了早期的一套命令行校验工具。这套工具用C写成解析速度快对畸形PDF的处理也更成熟。负责迁移到Java平台的技术团队为了保证功能一致性决定继续在Java服务里“外包”解析任务。于是Java层只需要把文件路径传给命令行程序再由命令行程序输出JSON结果。这个“外包”思路本身没有错错的是接口定义得太粗糙。它把一个需要强校验、强隔离的操作简化成了“拼命令、执行、读输出”三步。文件名作为一个不可信输入被直接当作命令参数来用而且没有借助ProcessBuilder的参数列表模式来规避shell解释。我在审计笔记里写了一段点评这是典型的“信任不可信输入”案例。代码里的每一行都像在做正确的事情保存文件、构造路径、调用命令、读取结果但组合在一起就把系统的最高权限拱手交给了文件名里的几个字符。3.3 在授权环境下的复现与验证思路写到这里必须强调任何漏洞验证都必须在授权环境中进行。我当时的操作是在一个完全隔离的测试环境里部署了目标系统的相同版本然后构造了一个文件名为poc.pdf;touch /tmp/audit_ok的上传请求。接口返回后我进入测试服务器检查/tmp/audit_ok文件是否存在。为什么选择touch这个无害命令因为它不会破坏环境又能干净地证明命令被执行。文件出现的那一刻基本可以确认RCE成立。后续我又用动态插桩的方式在Java层记录了Runtime.exec()的真实调用参数进一步确认了注入点和方法栈。需要注意的是这种验证方式千万不要在生产环境或没有授权的目标上尝试。漏洞验证的意义是证明风险存在而不是拿别人的系统练手。规范的流程一定是先获得授权再在隔离环境复现最后连利用痕迹都要清理干净。4. 修复与加固从补漏洞到建纵深防御4.1 先用最小改动堵住命令注入修复这个漏洞最直接的方式是把“拼接字符串”改成“参数列表”。Java 的ProcessBuilder天然支持这种安全的命令调用方式它不会把参数交给shell解释而是直接以argv形式传给操作系统进程。改造后的核心代码大概长这样public String verify(String fileName) throws IOException { // 对文件名做白名单校验只保留字母、数字、点、下划线 if (!fileName.matches([A-Za-z0-9._-])) { throw new IllegalArgumentException(非法文件名); } String tmpDir /tmp/uploads/; String targetPath tmpDir fileName; ProcessBuilder pb new ProcessBuilder(pdfverify, --file, targetPath); pb.redirectErrorStream(true); Process process pb.start(); return readOutput(process.getInputStream()); }第一处改动是文件名白名单。这个正则只允许常见的“安全字符”任何包含空格、引号、分号、管道符、$()等特殊符号的文件名都会被直接拒绝。第二处改动是用ProcessBuilder替代Runtime.exec()。两处合起来既堵住了shell注入也压缩了攻击者的构造空间。如果业务上确实需要保留一些特殊文件名那就不要用白名单而是用UUID重命名上传文件彻底摆脱对原始文件名的依赖。这也是我更推荐的方式系统内部统一使用随机生成的临时文件名原始文件名只在数据库里做记录永远不参与文件路径拼接。4.2 系统级隔离和权限控制不能省仅仅修补代码还不够RCE这类漏洞一旦发生真正决定损害大小的是系统自身的隔离能力。我给目标系统提出的加固建议包括几层运行pdfverifier的JVM进程使用独立低权限账号启动禁止使用root或管理员权限。将外部命令工具放进容器或沙箱限制它访问网络和其他目录的能力。上传文件存储目录使用内存临时文件系统或独立分区避免恶意文件落盘到业务数据盘。对上传接口做额外的文件类型校验不只依赖扩展名还要通过文件头魔数检测真实格式。部署Web应用防火墙对包含命令注入特征的上传文件名进行拦截。这些措施不一定每个系统都能一步到位但可以分批次落地。举个生活化的例子就像家里装了防盗门修复漏洞还不够安心的话再加装监控和报警器系统隔离就算防盗门被撬开还有第二道防线兜底。4.3 回归验证和自动化安全测试修完代码不是终点还要证明修复生效并且没有破坏原有功能。我在测试环境做了两轮回归第一轮叫“正向回归”就是拿一批正常的PDF合同文件跑验真流程确认签名校验结果和修复前保持一致。第二轮叫“安全回归”把之前能触发命令执行的恶意文件名重新上传观察接口是否拒绝、服务器是否产生新的异常。同时也用简单的方式验证了ProcessBuilder模式下文件名里的特殊字符只会作为普通参数传给工具不会被当成命令解释。持续集成方面我建议把这类用例沉淀成自动化测试。每次代码构建时自动跑一批畸形文件名和恶意PDF用例一旦出现新的命令拼接风险测试直接就红开发在提交阶段就能发现问题。这是性价比最高的安全投入之一。5. 代码审计实操心得与常见坑5.1 这类审计最容易踩的四个误区做PDF相关代码审计我见过不少人栽在下面几个坑里。第一个误区是只搜索Runtime.exec()不看ProcessBuilder。不少开发者知道前者危险于是改用ProcessBuilder但用法不对如果第一个参数是/bin/sh -c后面再拼接字符串那依然存在命令注入。搜索时要把两种方式都覆盖到。第二个误区是只检查文件名不检查内容字段。有些PDF解析器会把文件内的“文档标题”“作者信息”“字体路径”等字段提取出来如果这些字段被拼接到命令里同样会形成注入。很多审计人员因为只盯上传文件名漏掉了藏在PDF内容里的攻击面。第三个误区是忽略Windows和Linux的差异。有些代码在Linux上看起来安全换到Windows上却因为命令解析规则不同出现问题。比如路径分隔符、转义字符、批处理命令的行为都不一样。如果目标系统是可移植部署的两种平台都要评估。第四个误区是不看错误分支。比如文件解析失败后某些系统会把错误信息拼进一条 “debug 命令” 里打日志攻击者故意构造异常PDF反而能触发埋藏在错误处理路径里的危险函数。正向流程安全不代表反向流程安全。5.2 排查同类型RCE的速查清单为了方便后续审计我总结了一张“同类型漏洞快速排查清单”。无论是审计自己写的代码还是审查第三方项目都可以按这张清单过一遍全局搜索Runtime.getRuntime().exec、ProcessBuilder、ProcessImpl逐条确认参数来源。搜索/bin/sh、cmd.exe、bash -c等shell调用特征。搜索文件上传逻辑跟踪原文件名是否进入路径、日志、命令。搜索外部命令工具调用点确认是否用了参数列表方式。检查是否存在对PDF元数据、字体名、书签名等内容的提取和拼装。检查反序列化入口特别是XMLDecoder、ObjectInputStream、eval类的函数。最后把所有“不可信输入→危险操作”的数据流在代码里标红务必逐条人工确认。这张清单不需要多么高级的工具一张纸一支笔都能画完但对审计覆盖率很有帮助。5.3 漏洞披露和应急响应的正确姿势最后一个部分我想聊聊漏洞披露和应急响应。这里要特别强调边界发现漏洞后第一时间联系厂商或资产负责人在对方确认并发布修复方案之前不要对外公开漏洞详情。QVD编号被公开意味着漏洞已经进入公共情报库但这不等于我们可以跳过负责任披露流程。应急响应的顺序也很有讲究。第一步是确认漏洞是否已被利用检查服务器上有没有可疑进程、异常命令执行记录、可疑的临时文件。第二步是切断攻击链路比如封禁上传接口、下线受影响的组件、暂停相关服务。第三步是升级补丁并重新做一次全面排查。最后才是恢复业务恢复到正常流量后要持续观察日志一段时间确认没有残留后门。我在这次审计里还加了一步把pdfverifier组件的所有调用方全部列出来防止修复了A接口却发现B接口还是旧的调用方式。这种“牵一发动全身”的情况在大型系统里非常常见宁可多花时间在调用关系梳理上也不要等上线才发现漏修。这次审计最深的体会是安全往往藏在“不起眼”的代码里。pdfverifier 不是一个复杂组件但因为它天然要处理不可信输入又喜欢把脏活外包给外部命令就成了漏洞的温床。对我来说每一次代码审计都是一次“信任关系”的重建哪些输入可以信任哪些输入必须隔离代码里的边界画得是否清楚直接决定了系统的安全下限。希望这篇复盘能帮你在下一次审计时少走一点我走过的弯路。
