匿名 GitHub 账户批量发布未公开的 0-day

原文 ↗ Hacker News 讨论 ↗

漏洞利用的范围与质量

  • 许多读者查看了具体的 PoC（Ghidra、Docker、VLC、c-ares、libssh2、FFmpeg、PHP、nmap、Gitea），发现质量参差不齐：
    • 有些看起来确实严重（例如 c-ares UAF、libssh2、FFmpeg RCE、某些 nmap 解析问题、某些 Rustdesk / 逻辑漏洞）。
    • 另一些则很琐碎、归类错误，或需要本来就很危险的条件（覆盖磁盘上的二进制文件、已经拥有 PHP 代码执行、仅测试代码、仅崩溃案例）。
  • 有几位指出，“RCE”有时被宽泛地使用（例如 SSH root 会话，或者“代码执行导致代码执行”），而且很多条目看起来更像通用漏洞，而非高影响漏洞。

什么算作“0‑day”

  • 关于定义存在分歧：
    • 一派认为：“0‑day”意味着“在厂商或公众知晓之前已在野外被利用”。
    • 另一派认为：“0‑day exploit”指厂商有零天时间修补时可用的利用；“0‑day vulnerability”则是任何被这种利用影响的漏洞。
  • 有人认为这个术语被膨胀并被过度使用，变成了“任何未公开的漏洞”。

LLM、fuzzing 与自动化

  • 根据这些发现的数量、风格以及好坏混杂的结果，很多人强烈怀疑其中许多是由 LLM 或自动化 harness 生成的。
  • 有人声称当前强模型已经能发现大量真实漏洞；也有人抱怨 AI 驱动的报告经常夸大严重性或标记无关问题。
  • 讨论中提到，该仓库更新后的 README 声称其使用一个由 AI 模型在严格 harness 下自动化的自定义 fuzzing 工作流。

开源 vs 安全通过隐蔽

  • 一方担心，开源代码加上 LLM 会让大规模发现利用变得过于容易，并重新引发对“安全通过隐蔽”的兴趣。
  • 另一方反驳：
    • 攻击者本来也可以对二进制进行逆向工程。
    • 开源受益于众人审视以及 AI 辅助审计。
    • 只需要一方拥有强模型就能加固 OSS，而专有代码则是单一厂商的工具对抗所有攻击者的工具。

披露伦理与防御者负担

  • 有人认为，在未通知厂商的情况下批量公开 PoC 是不负责任的，理由是承担风险的是用户，而不是维护者。
  • 也有人说：
    • 负责任披露太慢，通常得不到回报，有时还会遭到法律威胁。
    • 公开倾倒可避免被政府或黑市独占使用，并可能迫使采用更好的做法（例如在发布前进行 AI 红队测试）。
  • 安全工程师抱怨来自低严重性或 AI 伪造报告的“噪音”，但也承认小漏洞有时可以串联成严重的利用路径。

更广泛的安全背景

  • 附带讨论涉及：
    • 依赖美国 SSN/银行号码的身份体系脆弱性，以及通过 ACH 进行欺诈。
    • 与加密货币持有相关的绑架/人身风险。
    • 需要对高风险解析器（媒体播放器、AV 引擎、网络分析器、CI runner）进行沙箱隔离，并假定 nmap、VLC 和 Wireshark 这类工具是高价值目标。