GuardDog这类供应链安全扫描工具最近因为Zip炸弹漏洞被曝出可导致拒绝服务攻击圈子里讨论热度不小。简单说就是一个看起来只有几十KB的压缩包经过层层解压后能膨胀到数百GB甚至TB级别直接把扫描进程的内存、磁盘和CPU全部打满整个扫描服务当场瘫痪。这个问题的危险之处在于它不需要什么高深攻击技巧任何人只要把一个精心构造的Zip包提交给扫描器就能触发属于典型的低成本、高收益攻击类型。我平时也会维护一些自动化安全分析脚本处理过不少类似场景可以负责任地说这类问题不只是GuardDog一家的事凡是需要解压并检查文件内容的安全工具基本都暴露在同一类风险下。这篇文章我把Zip炸弹的原理、GuardDog为什么会中招、攻击路径是什么、以及怎么给扫描器加防护这几块内容完整拆开讲清楚对做DevSecOps、自研扫描工具、或维护CI流水线的开发者都有直接参考价值。1. Zip炸弹为什么是扫描工具的天敌1.1 从一段恶意压缩包说起Zip炸弹的核心原理其实非常朴素利用压缩算法对重复数据的超高压缩率将大量数据塞进很小的压缩文件里。举个例子一个包含数GB连续零字节的文件用Zip压缩后可能只有几MB甚至几百KB因为全零字节的模式可以被打包成极小的标记数据。攻击者在此基础上还能做多层嵌套外层解开是一个小Zip再解开又套一个如此反复最终解压出来的数据量呈指数级增长。你可能听过著名的“42.zip”示例它在业界被讨论了很多年一个很小的文件通过层层解压能展开到几百TB的数据。更关键的是这个炸弹的解压过程本身不需要任何“恶意代码执行”它就是普通Zip解压只是数据量远超预期。所以任何负责处理不可信文件的程序从反病毒引擎、包管理审核器到安全扫描器都有可能被它拖垮。我在排查供应链安全告警时见过不少这种样本它们甚至不包含任何恶意代码纯粹就是来搞破坏的。攻击者的思路很直接不指望它能执行什么功能只要能消耗你的资源就够了。一个几百KB的文件就能让一台扫描节点磁盘写满、内存耗尽比很多复杂的漏洞利用要省事得多。1.2 安全扫描器的“必须解压”困境这里有个天然的矛盾很多不接触扫描器实现的人容易忽略安全扫描工具要检查包内文件是否有恶意行为就必须把文件真实内容读到内存或磁盘上然后才能跑正则规则、模式匹配、行为分析这些检测逻辑。GuardDog这类工具更是如此它扫描的是npm包、PyPI包、模型仓库里的内容而绝大多数发布制品都是以压缩包、归档文件的形式分发的。扫描器拿到一个包以后第一步几乎必然是解压这样才能访问到里面的Python脚本、JavaScript文件、Shell脚本等可分析对象。问题就出在这个“几乎必然”上。扫描器把压缩包视为需要检查的可疑输入但它在解压之前往往不会把压缩包本身当作“可能攻击资源限制的武器”来对待。换句话说安全工具在防外部攻击却在处理输入时缺乏对输入自身的防御。就像一个人穿着防弹衣进入房间却忽略了自己手里握着的那个即将爆炸的包裹。我用一个生活化类比帮理解你去快递站取了一个小盒子盒子外面写着“内含大量泡沫”你把它扔进碎纸机检查结果碎纸机被泡沫塞满了。扫描器面对的Zip炸弹就是这个泡沫盒它能安全处理的是“小盒子”本身但“装满整个碎纸机”超出了预期。1.3 拒绝服务攻击在这类工具里的现实损失很多人觉得拒绝服务嘛顶多就是进程崩了重启一下。但在真实的安全扫描场景里损失远不止“崩溃”这么简单。第一层损失是扫描任务本身。如果扫描器在解压阶段就崩溃了后面所有检测逻辑都不会执行这个包要么被当成“扫描超时失败”跳过要么导致CI任务红了。自动化流程为了不阻塞发布经常会在超时后做一个“宽松处理”比如标记为可疑但允许人工审核这就可能让恶意包带着“未完成检查”的标签流向下游。第二层损失是共享资源的雪崩效应。扫描器往往部署在CI集群或云端分析服务里一台扫描节点被Zip炸弹打挂后续排队的任务全部积压。如果这个服务承载了多条流水线一个炸弹样本就能造成上千个任务的连锁延期。云端环境尤其明显大量CPU、内存、磁盘IO被浪费账单还会直线上升。第三层损失是对工具信任度的破坏。安全扫描工具被一个简单压缩包打挂业务团队会立刻对整个安全流程产生怀疑。如果这次挂掉导致发布延期下回开发者就会想办法绕过扫描这比单个漏洞的危害要深远得多。2. GuardDog在供应链安全中的定位与暴露面2.1 GuardDog到底在扫什么GuardDog是一个面向开源生态的供应链安全扫描工具重点关注从npm、PyPI、HuggingFace模型仓库等渠道获取的可疑文件。它的工作模式是拉取目标包或模型对内部文件执行静态分析寻找恶意代码模式常见检测点包括可疑的远程下载函数、混淆的Base64编码数据、加密的矿工程序、后门脚本等。正因为检测粒度为“文件级别”GuardDog必须逐个文件读取内容。而它要处理的生态对象中大量组件都以Zip/Tar/Wheel等格式打包。比如Python的Wheel包本质上就是一个Zip归档npm包则是嵌套的Tar包。这意味着GuardDog的解压逻辑是所有检测流程的前置依赖任何解压环节失效整个扫描链路就会断掉。我也观察到这类工具普遍存在一个设计倾向开发者的主要精力放在规则引擎、特征模式、评分模型上对“文件解压这一步到底消耗了多少资源”往往缺少同等重视。规则写得再好如果文件根本还没走到规则那里扫描器就倒了那这套检测体系的实际防护能力就等于零。2.2 从攻击者视角看扫描器安全从业人员有个习惯喜欢把自己当防御者但分析漏洞时换个视角可能更有价值。站在攻击者这边想我要往供应链里投放一个恶意包第一步会经历什么当然是自动化审核和扫描。如果我能让扫描器失效我的恶意包就获得了极大的生存空间。Zip炸弹在这里扮演的角色就是“干扰弹”和“烟雾弹”的组合。攻击者可以构造这样的包裹里面既有炸弹成分又夹杂着真正的恶意脚本。如果扫描器崩了管理员看到一个“解压失败”或者“扫描超时”的告警注意力反而会被引到技术故障上去而不是怀疑包本身有问题。更精巧的攻击思路是把炸弹藏在多层嵌套中。比如前两层看起来正常第三层突然是超高压缩比的火焰。扫描器如果在第一层或第二层还有配额控制到第三层就可能彻底失控。攻击者完全可以在线测试自己的包裹在不同扫描器、不同资源配额下的表现像调参数一样精细化设计炸弹的有效性。这个视角说明了“影响范围”的一个关键点Zip炸弹漏洞不仅影响工具稳定性还会破坏整个供应链审核链路的完整性。攻击者不需要正面突破检测规则只需要让自动化审核无法完成就能大幅提高恶意包存活率。2.3 为什么这类问题容易出现在“检查逻辑之外”我要强调一个实际观察这类漏洞很少是某个安全检测算法写得不对而是发生在“非检测路径”上。也就是说在开发者的心智模型里“解压并读取文件”被认为是基础操作默认它一定能顺利完成因此不会为它设置太多的防御边界。这就像你把钱存进保险箱但银行大楼却允许任何人随意参观地下室因为“地下室的安保不属于保险箱业务范围”。攻击者注意到这个盲区后会专门从非防御区域下手毕竟那里往往没有足够的监控和限制。我见过不少自研扫描工具的代码解压逻辑大多是这样的下载文件调用系统unzip命令然后遍历临时目录里的所有文件。整个过程没有大小上限、没有文件数上限、没有解压时长限制、没有磁盘配额。这在处理少量受信文件时还行一旦暴露在公网输入面前就是一个个装满炸弹的射击靶子。GuardDog曝出的这个Zip炸弹问题本质上也是同一个套路工具太信任输入忘了给输入处理过程加保险丝。3. Zip炸弹漏洞的技术拆解与攻击路径3.1 炸弹是怎么构造出来的我不打算在这里给出完整的攻击样本构造代码但我把原理讲透因为防御者必须理解攻击者的构造方式才能设防。最基础的单层炸弹很简单创建一个巨大的文件里面的数据是高度可压缩的比如全零字节然后用标准压缩工具打成一个Zip。由于文件内容冗余度极高压缩包体积会非常小而解压后体积会瞬间恢复到原来的大小。如果你在文件系统中创建了一个比如5GB的稀疏文件再压缩压缩产物可能只有几MB。更危险的是多层嵌套炸弹。每一层都是一个小Zip但里面装的不是真实数据而是另一个Zip文件。每解压一层得到的还是一个小文件但它的解压目标又是下一层如此往复。等层数足够多最内层展开的数据量可以超出任何合理预期。这种嵌套结构还有一个作用绕过简单的“解压后单文件大小检查”因为每一层的文件大小看起来都正常。还有一类变体是“组合炸弹”既有超大单文件又有海量小文件。比如一个Zip里包含数十万个文件虽然每个文件只有几个字节但解压成千上万个文件本身就要消耗大量文件系统inode和CPU时间。扫描器逐个打开、读取、分析这些文件光遍历的开销就足够把任务拖成超时。3.2 扫描器是如何一步步被拖垮的以GuardDog的典型工作流程来看触发点通常在“下载包”之后的“解压检查”阶段。具体流程可以这样理解第一步工具从包仓库拉取目标资源。第二步识别到它是Zip/Wheel/PyPI包等压缩格式准备解压。第三步调用解压逻辑把所有实体文件释放出来。第四步遍历解压后的文件逐个送入规则引擎。Zip炸弹的攻击点精确落在第三步。如果解压到磁盘炸弹会迅速占满临时目录的磁盘空间。如果实现中先将部分内容读入内存再判断格式则可能直接耗尽内存。而Zip的解压本身是CPU密集型操作多层的嵌套炸弹会让CPU在大量重复解压中被打满。这三种资源中的任何一种耗尽都足以让扫描进程被系统杀掉。比较微妙的是有些扫描器为了防止超时会设置一个总的执行时限。攻击者当然不会放过这一点炸弹不需要让扫描器崩溃只要能拖到时限耗尽任务一样会以失败告终。从这个角度看Zip炸弹攻击可以非常“精准”目标就是“我要让你在这件事上耗费巨大成本”。3.3 影响范围分析我把这个漏洞影响的层次梳理成一张表方便对照自己所在场景评估风险影响层具体表现危害程度本地扫描进程进程解压时磁盘写满、内存OOM被系统杀死中进程崩溃单个任务失败CI/CD流水线扫描任务超时或失败流水线红掉发布阻塞高业务迭代被拖断云端扫描服务共享资源被大量占用大量任务排队拥塞严重整个服务不可用成本飙升供应链审核链路扫描失效导致恶意包漏检进入下游环境严重安全防线形同虚设下游用户环境被恶意包植入后门、挖矿程序等严重真实安全事件这个表说明了同一个漏洞在不同部署形态下的巨大差异。如果你只是在本机跑一个简单的CLI扫描最坏结果就是进程退出但如果你把GuardDog或同类工具封装成企业内部的云扫描服务攻击面就完全不一样了一个Zip炸弹可以让一个共享分析平台直接瘫痪。4. 防御与修复实操给扫描器的解压逻辑上枷锁4.1 预算式解压在写文件之前先算账我之前维护扫描服务时踩过不少坑最有效的通用方案就是“预算制”。核心思路是解压任何不可信压缩包之前先读取压缩包的元数据信息不实际解压内容把文件大小之和、压缩率比例、文件数量等数据估算出来然后跟预设阈值比较超了就拒绝处理。拿Python的Zip解析来举例zipfile模块的每个信息条目里都有两个关键字段file_size是解压后的大小compress_size是压缩后的大小。遍历所有条目这些字段就能在不解压的情况下完全掌握全局。下面是一个简化的预算检查框架我实际项目里也是类似写法加了注释方便理解import zipfile import sys # 预设的资源配额 MAX_TOTAL_UNCOMPRESSED_SIZE 5 * 1024 * 1024 * 1024 # 解压后总大小上限5GB MAX_FILE_COUNT 50000 # 文件数量上限 MAX_SINGLE_FILE_SIZE 500 * 1024 * 1024 # 单文件解压后上限500MB def check_zip_budget(path): with zipfile.ZipFile(path) as zf: total_size 0 file_count 0 for info in zf.infolist(): if info.is_dir(): continue file_count 1 total_size info.file_size if info.file_size MAX_SINGLE_FILE_SIZE: raise RuntimeError( f单文件过大: {info.filename} 解压后大小 {info.file_size} ) if total_size MAX_TOTAL_UNCOMPRESSED_SIZE: raise RuntimeError( f解压总大小超限当前累计 {total_size} ) if file_count MAX_FILE_COUNT: raise RuntimeError( f文件数量超限: {file_count} ) print(f预算检查通过: 共 {file_count} 个文件总大小 {total_size} 字节)这段代码有个重要特点它只读元数据不碰实际内容。即使压缩包包含恶意数据这段检查本身不会触发解压所以不会给攻击者任何消耗资源的机会。真正解压之前先把这个预算检查当作强制前置步骤。4.2 限制层级、文件数量与递归嵌套Zip炸弹经常会用多层嵌套来绕开单层预算所以仅仅检查一层还不够。扫描器需要显式管理解压深度并限制递归解压行为。具体来说每遇到一个嵌套的压缩文件解压深度加一层深度超过预设值就停止。我在项目里常见的做法是三个维度同时限制解压深度默认最大3层超过即拒绝正常代码包极少超过2层。文件数量解压出的实体文件数量总上限单个Zip内部文件数建议不超过5万太多的小文件本身就可能是攻击方式。总解压字节数所有层级的解压后字节数累加控制这个数值才是真正决定资源消耗的指标。这里还要专门提一个容易被忽略的细节递归解压时的存储策略。如果你把每一层嵌套的Zip先释放到临时目录再打开下一层临时目录的磁盘占用会成倍增加。更好的思路是把内层嵌套Zip先读进内存缓冲区用io.BytesIO保存然后直接用BytesIO对象创建新的Zip解析器不落盘到临时目录。但是要注意内存缓冲策略意味着嵌套数据会占用内存。这时候对单层Zip解压后总字节数的限制就变得很关键它可以和内存配额匹配起来。一般来说解压预算应该略低于扫描进程可用的最大内存否则预算还没触发内存先爆了。4.3 运行环境兜底容器限制是最后防线就算代码里做了预算检查现实世界总会有意外比如解析器对畸形Zip的处理方式、极端情况下的路径问题都可能绕过预算。所以运行环境层面一定要有硬性兜底我个人建议把扫描服务套上容器资源限制。用容器跑扫描器是业内很常见的部署方式可以在启动参数里直接圈定资源上限docker run --rm \ --memory2g \ --memory-swap2g \ --cpus2 \ --pids-limit512 \ --read-only \ --tmpfs /tmp:size1g \ guarddog-scan:latest上面这组参数我解释一下--memory2g和--memory-swap2g限制容器最多使用2GB内存超过就被OOM杀死即使代码预算失守内存也有最后防线。--cpus2限制CPU用量避免解压过程把所有核心打满。--pids-limit512限制进程数防止某些恶意包尝试fork大量子进程。--read-only让根文件系统只读减少恶意包写文件的可能。--tmpfs /tmp:size1g把临时目录映射成内存盘并限制最多1GB空间这相当于把磁盘配额也圈住了。这套配置的关键在于“即使我代码有bug环境也会兜住”。对于攻击者精心构造的畸形包代码逻辑出意外完全可能但容器配额不会骗人。如果扫描器不是跑在容器里用systemd跑服务时也可以加MemoryMax、TasksMax等限制达到类似效果。总之一句话解压逻辑代码负责“提前拦截”运行环境配额负责“最后兜底”两把锁缺一不可。4.4 日志与监控扫描被中断比扫描放行更值得警觉还有一个很有价值的防御习惯把扫描失败和中断统一记录下来并发送告警。我之前团队里每个扫描任务的退出码和失败原因都有上抛不仅是为了排查bug更是为了发现攻击行为。很多安全团队习惯盯着“检测到恶意样本”这个指标但Zip炸弹这类攻击的目标恰恰是“让检测无法完成”。如果只是静默地处理超时任务攻击者反复试探的痕迹就不会被注意到。正确的做法是把每一条“解压预算超限”“内存被杀”“解压超时”都记录成安全事件而不是当成普通错误。看起来很小的一个习惯实际上能在早期发现攻击者的试探行为。攻击者不可能一次成功他们需要反复提交不同构造的样本测试扫描器留下的大量“预算拒绝”日志就是最好的攻击预警信号。把这些失败样本归档保存以后还能用来验证防御升级有没有生效。5. 实操过程中的坑与排查记录5.1 只看压缩后大小的认知陷阱我在评估一个可疑包时第一眼也习惯看文件大小几百KB确实会让人放松警惕。但Zip炸弹的设计目标就是让“压缩后大小严重误导人”压缩率可能超过一万倍。有团队曾经以“包大小不超过10MB”作为安全准入条件这个策略对普通文件或许有效但对炸弹类型文件几乎没有作用。因为一个10MB的Zip炸弹完全可能解压出数十GB数据。所以排查时不要只记录压缩包大小还要记录解压预算相关的几个数字总文件数、累计解压大小、最大单文件大小、压缩比率。当压缩比异常高时比如压缩后只有1MB、解压后预估超过1GB就应该立刻触发告警。5.2 “小文件海啸”攻击另一种容易被防御策略漏掉的攻击是海量小文件。一万个文件每个只有几KB总大小也许只有几十MB看起来完全在预算内但打开、读取、关闭IO路径上的重复成本会累加成巨大的开销。处理这种攻击需要在预算里同时加入文件数量限制。代码里设置一个合理的文件数上限超过直接拒绝远比放任扫描器逐个打开文件更高效。对于某些场景如果确实需要分析大量小文件应该走批处理队列而不是一次性全部展开。5.3 Zip元数据可能不可靠预算检查依赖ZipInfo.file_size字段但这里有一个隐藏的坑不是所有Zip文件都会正确填写这个字段。当Zip使用了数据描述符data descriptor且没有正确的本地头信息时file_size字段可能为零或异常。因此预算检查应该被当作“第一道粗筛”真正的安全底线是边解压边实时统计。解压过程中如果发现实际字节数超过了粗筛阈值立即中止。我处理这类问题时会在遍历解压文件流时维护一个实时累计值每次写入前检查是否超过了当前预算严格控制超限后的写入行为。5.4 不止ZIPtar、gz、xz、7z都有同类问题我特别想强调不要把防御焦点只放在Zip上。现在很多恶意包用.tar.gz、.tgz、.xz甚至是7z格式分发。tar格式尤其麻烦因为它没有中心目录无法像Zip那样提前读取所有文件大小做预算只能流式解析。这意味着针对tar类归档文件预算检查必须放在读取流的同时进行。我在踩过几次坑之后总结出的实用方案是在解压逻辑外层做一层“流大小限制”实时记录已解压的字节数每处理一个文件前检查这个总数一旦突破上限就立刻中止不迷信任何头部元数据。另外Python生态的Wheel包本质是Zip但npm包可能是tar。混合格式嵌套也常见比如先解压tar.gz里面又套了一个Zip。所以预算控制必须是“递归式”的每种格式的处理函数都要接受同一个预算对象而不是各自的独立逻辑。5.5 路径穿越和符号链接别把炸弹和一个坑混在一起Zip炸弹的防御是资源维度而Zip还经常携带另一个问题路径穿越也就是所谓的Zip Slip。攻击者可能在压缩包的文件条目里写上../../etc/cron.d/evil如果扫描器直接extractall就有可能在扫描主机上写入任意路径的文件。给扫描工具做防护时这两类问题应该一起处理。解压前必须过滤异常的路径拒绝包含绝对路径、..段、符号链接指向外部路径等情况的条目。我在代码里会统一把info.filename做规范化用os.path.normpath解析后再判断当前活动目录前缀确保所有解压目标都落在预期的临时目录内。这一点尤其容易被新手忽略你以为他在攻击你的内存其实他也在准备覆盖你的home目录。6. 从Zip炸弹到更广的供应链安全思考6.1 安全工具自身也是攻击面这次GuardDog的Zip炸弹漏洞被曝出来我认为最有价值的启示在于安全工具本身也是攻击面。攻击者完全不需要尝试绕过检测规则他只要攻击扫描器处理数据的前置链路就能让整套防御体系失效。过去安全团队评估攻击面时往往把注意力放在业务应用、数据库、网络边界这些“正式资产”上。但扫描器、CI代理、日志分析器这类“安全基础设施”平时被视为可信组件受到的防护力度反而更弱。攻击者通常更懂得利用这种盲区。我见过一些企业内部的威胁情报平台每天会拉取大量外部样本做分析但对接入样本的压缩包大小、解压深度、嵌套层数几乎没有限制。这类内部系统一旦暴露给不可信输入中招概率非常高。所以每当有人问我“扫描器要不要防Zip炸弹”我一般反问你的扫描器到底在防谁如果答案里有“不可信外部输入”那就要防。6.2 修完GuardDog你的其他解压代码呢每次安全通告出来很多人第一反应是检查自己的GuardDog版本是否需要升级。但我的习惯是借这个机会做一次全面的解压行为审计把项目里所有涉及unzip、extractall、tar -xf、archive操作的位置全部找出来。因为原理是一样的Zip炸弹能打GuardDog自然也能打你自研的任何一个解压脚本。CI里下载构建缓存并解压的步骤、爬虫下载附件并解析的模块、邮件网关扫描附件的组件全都是潜在暴露面。在审计时我会用几个简单的问题快速判断风险解压前有没有预算检查解压有没有深度限制临时目录有没有磁盘配额运行进程有没有内存和CPU限制如果四个问题的答案都是“没有”那么这段解压逻辑就处于裸露状态需要尽快加上防护。6.3 防御思维要从“检测恶意”升级到“防护检测过程”这次事件给我的真实感受是做供应链安全不能只关心“能不能检出恶意代码”更要关心“检测过程本身能不能扛住恶意输入”。安全扫描器的第一任务不是强大而是稳定一个能被简单文件打挂的扫描器无论规则写得多好都等于没有扫描器。我自己在维护扫描服务时最深的体会是资源预算不是一个锦上添花的优化手段而是安全工具的基础功能。它和权限校验、输入校验一样都是处理不可信数据时必须先做好的安全保障。把预算检查从“可选配置”改成“默认强制”能从很大程度上把这类漏洞从源头上堵住。最后分享一个小技巧在把新的扫描器部署到生产环境之前先准备一组畸形压缩包测试样本包含单层炸弹、嵌套炸弹、海量小文件、路径穿越等场景跑一遍回归测试。这组样本不需要很大但能有效验证你的防御策略是不是真的生效。踩过几次坑之后你会感谢这组测试样本。