跳转至

Getting a CVE Without Shipping Slop

Ch12.073 Getting a CVE Without Shipping Slop

📊 Level ⭐⭐ | 5.8KB | entities/getting-cve-without-shipping-slop.md

Getting a CVE Without Shipping Slop

来源: credrelay.com 作者: Jeff (Cred Relay Newsletter) 发布日期: 2026-06-16

摘要

作者使用 Claude Code + Ghidra MCP 工具链成功获得两个 ASUS 驱动 CVE（CVE-2026-3508 和 CVE-2026-6737），并总结了 AI 辅助安全研究中"不发垃圾报告"的核心原则。文章展示了 AI 辅助逆向工程的实战流程：从驱动筛选、逆向分析到 PoC 编写，同时强调了人工验证的不可替代性。

核心要点

1. 工具链与方法论

  • cthaeh: 作者自建工具，基于自定义标准对驱动进行优先级排序，排除已知被覆盖的驱动（如 Microsoft 驱动）
  • Ghidra MCP: 通过 MCP 协议让 Claude Code instrument Ghidra，实现 AI 辅助逆向工程
  • Claude Code: 辅助逆向分析和 PoC 代码生成——"生成 C 代码比手写快得多"
  • 关键前提: 研究者必须能读懂 C 代码，知道"正确"长什么样

2. CVE-2026-3508: AsusWmiAcpi.sys 越界读取

属性 详情
驱动 AsusWmiAcpi.sys (ASUS System Control Interface)
版本 2.1.68.0 (asussci2.inf 3.1.57.0)
IOCTL 0x22240C (IOCTL_ATK_ACPI_WMIFUNCTION)
类型 Out-of-bounds read
CVSS 6.8 Medium

根因分析: 驱动接受 METHOD_BUFFERED IOCTL 输入，内部包含 InBufferSize 字段。驱动检查 claimed size 是否适配目标 buffer，但未验证调用者是否实际发送了足够数据。PoC 构造 12 字节请求但声称有 0x400 字节 payload，驱动信任该声明并从 kernel memory 越界读取。

3. CVE-2026-6737: AsusPTPFilter.sys 权限缺陷

属性 详情
驱动 AsusPTPFilter.sys (ASUS Precision Touchpad Filter)
类型 Exposed IOCTL / Insufficient Access Control
CVSS 2.0 Low
修复版本 16.0.0.46+ (通过 Windows Update)

根因分析: 驱动使用 IoCreateDevice 创建命名设备对象时未提供显式 SDDL/device security descriptor，Windows 应用默认权限允许标准本地交互用户打开这些对象。安全做法应使用 IoCreateDeviceSecure 或 WdmlibIoCreateDeviceSecure 配置 administrator-only DACL。

可达设备: \\.\AsusHITBIService, \\.\AsusHITTP, \\.\AsusTPCC, \\.\AsusTPGM, \\.\AsusTPPC, \\.\AsusHidService, \\.\FingerPrint

可触达 IOCTL: 0x220408 (驱动字符串读取), 0x220400 (固定偏移写入), 0x220420 (注册表参数读取), 0x2205B8 (状态/注册表处理器路径)

4. 反 slop 三原则

  1. 用 PoC 验证漏洞: 只报告能证明的东西——"finding was only real once it can be proven with a PoC and I understood what was happening"
  2. 承认自己的无知: 模型会 gaslight 你，如果你无法识别错误假设就会被误导
  3. 手动编辑或重写报告: AI 报告 verbose 且容易被识别，需要人工润色

深度分析

AI 辅助逆向工程的现实边界

这篇文章是 AI 辅助安全研究的罕见实战案例。与 hype 不同，作者明确指出 AI 的角色是"辅助"而非"替代"：

  • AI 擅长: 生成 C 代码、加速逆向分析迭代、快速 draft PoC
  • AI 不擅长: 判断漏洞是否真实存在、区分真实发现与 hallucination
  • 人不可替代: 理解根因、验证 PoC 可靠性、编辑报告质量

这与 Coding Agent 架构 的整体趋势一致：AI 作为 force multiplier，但 domain expertise 仍是核心竞争力。

METHOD_BUFFERED 的经典陷阱

CVE-2026-3508 本质上是 Windows 驱动开发中的经典错误——信任用户态传入的 size field 而不验证实际 buffer 内容。METHOD_BUFFERED 的 SystemBuffer 大小由 max(InputBufferLength, OutputBufferLength) 决定，但驱动不应信任 buffer 内部声明的 size。这类漏洞在 IoT 和 OEM 驱动中极为常见。

低分 CVE 的价值

CVE-2026-6737 仅 CVSS 2.0，但作者指出"Did you know you could get a CVE for a low?"——低分 CVE 仍有价值：它证明了安全研究的完整性，且修复后可消除攻击面。对于 漏洞披露实践 实践而言，不要因为预期评分低就放弃报告。

实践启示

  1. 工具链建设: Ghidra MCP + Claude Code 是可复用的 AI 辅助逆向工程工具链，值得安全团队搭建
  2. 驱动优先级排序: 自动化工具 (如 cthaeh) 可帮助筛选值得投入时间的驱动目标
  3. PoC 为王: AI 辅助发现的漏洞必须有可运行的 PoC 才能提交报告——这是防止 slop 的核心防线
  4. 驱动安全审查: OEM 驱动中 IoCreateDevice vs IoCreateDeviceSecure 的使用应纳入静态分析规则
  5. AI 报告质量控制: AI 生成的漏洞报告 verbose 且易被识别，需要研究者深度编辑

相关实体

→ 原文存档