PHP2Shell：AI 发现 PHP 中的关键 RCE

原文 ↗ Hacker News 讨论 ↗

借助 AI 的代码分析发现了 PHP 核心中的两个关键远程代码执行漏洞，而 PHP 通过 WordPress、Drupal 和 MediaWiki 等平台支撑着大量网络服务。评论者讨论了长期存在的 C 语言内存安全问题为何在数十年的 PHP 代码中未被发现、责任披露时间线与泄露过程为何混乱，以及多个 AI 模型和安全公司在发现与公开这些漏洞中的作用。线程还扩展到对遗留技术栈的担忧、加固 PHP 部署的现实可行性，以及对于高暴露互联网服务，是否应以更内存安全的语言和更激进的沙箱机制取代基于 C 的解释器。

影响与范围

  • 讨论一致认为，考虑到 PHP 的主导地位（WordPress、Drupal、论坛、Webmail、LMS、Nextcloud 等），这个 RCE 是件非常大的事。
  • 有人将其类比为 Log4Shell，甚至在潜在影响上可比 EternalBlue；也有人指出，漏洞利用的可靠性以及现实世界中的破坏程度仍不清楚。
  • 各国政府和 CERT 正在让站点下线，或发出最高级别警报；管理员们正忙着打补丁，或在 PHP 前面加上缓解型代理。
  • 少数人认为，正确隔离的 Web 服务器不应该这么容易成为“入门切口”，但很多人也承认，在现实中它们往往就是这样。

AI 的角色

  • 使用了多个来自不同厂商的 AI 系统来做代码扫描、漏洞利用开发、验证和检测。
  • 评论者认为这是 AI 的一个强应用场景：AI 可以啃下人类很少审查的、存在了几十年的 C 代码。
  • 也有人批评其中浓重的营销、品牌包装以及“tech-noir”式写法，并担心对 AI 作用的炒作过头。
  • 讨论的焦点之一是，AI 是真正发现了新的东西，还是重新发现了此前已报告或部分修复的问题。
  • 一些人担心面向防守方的模型被过度设限，而攻击者却可以使用限制更少的工具。

披露时间线与泄露

  • 该问题在 8 月被报告，9 月底被 PHP 方面确认，10 月底打补丁并公开披露；许多人觉得以其严重程度来看，两个月太久了。
  • 围绕此前一个被标记为已修复的 OOM 漏洞存在混乱；评论认为更早的修复只针对了局部问题，没有解决更广泛的根因。
  • 协调披露涉及许多厂商和发行版，增加了泄露风险。
  • CVE 编号和不准确细节提前泄露，随后一家公司又意外发布了 PoC 视频；另一家厂商在禁发期结束前数小时就发布了已修补镜像，因此受到批评。

技术与语言层面的问题

  • 这些漏洞根植于非常老旧的 C 代码：OOM 处理、use-after-free、PHP session upload progress、HashTable 内部、OPcache 等。
  • 几条评论都指出，一旦可以发生堆破坏，通常就能通过函数指针或类似原语实现 RCE。
  • 长篇子线程在争论 C 是否“并不适合其用途”，尤其是面向互联网的软件；也有人认为 C 没问题，但需要极强的纪律和工具支持。
  • 很多人主张把关键组件迁移到内存安全语言，并更多依赖沙箱与严格隔离。

PHP 生态与替代方案

  • 讨论重提了 PHP 的无处不在和“遗留但庞大”的地位，尤其是通过 WordPress。
  • 一些系统管理员早已把 PHP 服务器当作敌对环境对待（隔离 VLAN、加固配置），现在觉得自己的做法得到了印证。
  • 还有人把这作为另一个理由，推动迁移到基于静态站点的方案，或非 PHP 的 CMS 解决方案。