跳转至

PatchEval 面试 Case 卡

1. 主讲 Case：CVE-2021-21360

推荐把这个作为主案例。它适合回答“为什么多阶段 Agent 比单 Agent 好”“Analyzer 到底有什么价值”“78/230 之外能不能讲一个具体例子”。

CVE Description

Products.GenericSetup is a mini-framework for expressing the configured state of a Zope Site as a set of filesystem artifacts. In Products.GenericSetup there is an information disclosure vulnerability - anonymous visitors may view log and snapshot files generated by the Generic Setup Tool.

CWE: - CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

先把这个漏洞讲明白

CVE-2021-21360 是未授权信息泄露漏洞，对应 CWE-200: Exposure of Sensitive Information to an Unauthorized Actor。漏洞描述明确说：匿名访客可以查看 GenericSetup Tool 生成的 log 和 snapshot 文件。更口语一点说，就是“系统生成了一些本来只该管理员看的内部文件，但匿名用户能通过 URL 直接看到”。

它出在 Products.GenericSetup。GenericSetup 是 Zope / Plone 生态里的一个配置导入导出工具。管理员可以用它把一个站点当前的配置导出来，形成一份 snapshot。这个 snapshot 可以用来备份、迁移、对比站点配置。

为什么 snapshot 敏感？因为它不是普通图片或 CSS，而是站点配置的导出结果，包含 import/export step、插件配置、workflow、role mapping、权限相关配置等内部信息。即使里面不一定有明文密码，暴露这些配置也会帮助攻击者理解站点结构和安全边界。

攻击者模型也很简单：匿名访客。他不需要登录管理后台，就能查看 GenericSetup 生成的 log 或 snapshot 文件。这个点很重要，因为 Zope 里的对象不只是“磁盘文件”，很多对象会通过对象发布 / URL traversal 暴露成可访问 URL。

漏洞根因是：GenericSetup 在工具对象下面动态创建了 log、snapshot folder、snapshot data file 这些子对象，但访问权限没有一致收紧。代码里 log / report 文件创建后会显式把 View 权限限制到 Manager、Owner；snapshot folder 和真正保存内容的 snapshot data file 却没有做同样的 View 权限限制。这样就形成了权限策略不一致：一类内部文件被保护了，另一类内部文件沿用了不安全的默认访问行为。

所以这不是 SQLi、XSS、SSRF 那类“用户输入进入危险函数”的漏洞。它是内部导出文件暴露给未授权用户的信息泄露漏洞；从根因上讲，是动态创建的对象缺少对象级访问控制。

一句话版本

这个 case 是一个未授权信息泄露漏洞：GenericSetup 会生成站点配置 snapshot，而匿名访客可以查看这些生成文件。多阶段的收益在于 analyzer 先把修复边界讲清楚了：要保护的不只是 snapshot folder，还有真正保存导出内容的 snapshot data file；两者都需要像 log 文件一样收紧 View 权限。

30 秒口语版

我会讲 CVE-2021-21360。这个漏洞其实可以类比成：后台有个“导出站点配置备份”的功能，导出来的东西本来只该管理员看，但它生成出来以后权限没设好，匿名用户也能通过 URL 看到。所以它是信息泄露，CWE 是 CWE-200。

具体到代码里，GenericSetup 会生成两类东西：一类是 log / report，一类是 snapshot。log 文件创建后有明确的 View 权限限制，只给 Manager 和 Owner 看；但 snapshot 这边会先建 folder，再往里面写具体的 data file，这两层都没有同样收紧权限。多阶段 Agent 的价值就在这里：analyzer 先把“folder 和 file 都是修复边界”讲清楚，mitigator 才不容易只修 folder、漏掉真正保存内容的 file。

拆开记

这个漏洞可以按五句话记：

  • 类型：信息泄露，CWE-200。
  • 谁能看：匿名访客。
  • 看到了什么：GenericSetup 生成的 log 和 snapshot 文件。
  • 为什么能看：snapshot folder 和 snapshot data file 没有像 log 一样限制 View 权限。
  • 为什么适合讲 Agent：单 Agent 容易只修 folder，多阶段 analyzer 会先把 folder + file 的完整修复边界讲出来。

修复到底改了什么

正确修复思路是把 snapshot 相关对象的 View 权限显式收紧，和 log 文件保持一致。也就是说：

  • 创建 snapshot folder 后，要限制它的查看权限。
  • 写入 snapshot data file 后，也要限制这个文件对象的查看权限。

Default 多阶段 patch 的关键点就是两处都覆盖了。单 Agent 的问题是更容易只保护 folder，漏掉 folder 里面真正承载导出内容的 data file。

面试官可能追问

Q：这个 case 证明了 analyzer 一定有用吗？

不能这么说。它证明的是在一些修复边界比较容易漏的任务里，先做独立分析会有帮助。整体数据上 Default 是 78/230，Single-Agent 是 73/230，不是巨大提升；但这种 case-level difference 能说明多阶段确实改变了修复策略。

Q：为什么单 Agent 会漏？

我的理解是单 Agent 一边分析一边修，很容易被第一个看起来像入口的函数吸住。安全修复经常不是改一个函数，而是要看同一类对象、同一类权限策略有没有一致应用。Analyzer 的作用就是在写 patch 前先把这个边界说清楚。

Q：这个漏洞是什么类型？

这是信息泄露，CWE 是 CWE-200。如果从根因讲，就是对象级访问控制不完整。它不是 SQLi、XSS 那种输入进入危险 sink 的漏洞，而是内部生成的配置快照对象没有设置正确访问权限，导致本来应该只给管理员看的内容被匿名用户读到。

Q：为什么 folder 和 file 都要修？只保护 folder 不行吗？

folder 是容器，file 才是真正保存 snapshot 内容的对象。Zope 这种对象发布模型里，子对象也可能有自己的访问权限，不能只靠父目录权限来兜底。所以修复时 folder 和 data file 都要显式收紧 View 权限。

Q：这个例子和真实安全审查有什么关系？

真实 review 里也经常这样：一个漏洞报告说“某类文件能被访问”，但真正修的时候要确认所有生成路径、所有对象类型、默认权限和现有保护。这个 case 正好把这种 review 思路体现出来了。

Q：如果面试官完全不了解 Zope，怎么快速类比？

可以类比成一个后台系统有“导出配置备份”的功能。备份文件本来应该只有管理员能下载，但系统把备份文件放到了 Web 可访问路径下，而且没有给这个文件设置管理员权限。结果普通访客可能直接访问 URL 下载配置备份。这个 CVE 的具体技术背景是 Zope 对象发布和 GenericSetup snapshot，但安全本质就是这个。