Laravel Cloud 紧急修补 PHP 和 Node.js 关键漏洞

10月20日晚，我们收到预警：PHP和Node.js即将发布针对严重漏洞的安全修复程序。不到24小时，修复程序公开，所有Laravel Cloud应用都需要修补PHP。我们未发现任何证据表明有客户因这些漏洞而遭到利用。

本文介绍我们做了什么、哪些方面进展顺利、哪些方面存在不足。Laravel Cloud、Forge、Envoyer和Vapor都需要不同的处理，耗时最长的产品正是我们汲取大部分经验教训的地方。

PHP和Node.js于10月21日各自发布安全版本。PHP版本修复了两个严重的远程代码执行漏洞，Node.js版本修复了十个漏洞，其中包括一个可能允许远程代码执行的Brotli解码器缺陷。

PHP项目于10月20日19:58 UTC向我们提供了预先通知，公开版本于次日13:38 UTC发布。细节被有意精简，这正是负责任披露的应有方式。但知道漏洞存在就足以让人开始搜寻，而且消息已经在网上传播。我们只有不到24小时来修补整个集群。

大多数情况下，我们通过更新基础镜像来处理CVE，并通知客户需要部署以拉取最新镜像并获取修复。我们通常避免强制重新部署，原因有两个。全集群重建速度缓慢，在关键时期可能需要数小时。应用程序还会运行自己的部署命令，其中可能包括数据库迁移、通知和文件更改，我们无法确定哪些可以安全地代客户触发。

这个漏洞足够严重，我们希望我们管理的每个工作负载都得到修补，因此我们需要第二套方案。

在构建真正的修复程序的同时，我们增加了一层不依赖任何补丁的保护。10月21日08:55 UTC，在PHP版本公开前数小时，我们为Cloud域启用了Cloudflare的托管防火墙规则集，包括较新的规则，用于标记传入请求中的远程代码执行和异常代码执行。到10:24 UTC，我们为Forge和我们的专用区域添加了其中一小部分较新规则。防火墙无法覆盖此类漏洞的所有路径，因此这些规则减少了暴露面，但并未替代补丁。我们保留了这些规则，因为它们会在流量到达客户应用程序之前进行检查，为每个应用程序（无论是否已修补）提供针对此类请求的额外一层防护。

我们通常通过官方Docker Hub镜像获取PHP。由于许多人将同时拉取PHP和Node.js，我们不确定这些镜像重建的速度有多快。

因此我们规划了两条路线，并决定采用先奏效的那条。Docker Hub开源了其镜像构建方式，因此我们可以复制编译过程，在版本发布的那一刻自行构建已修补的PHP。最终，我们在14:24 UTC发布了自己的镜像，并使用了它。Docker Hub直到发布后数小时才有修补后的镜像，而我们镜像构建所依赖的一些第三方下载主机当天部分时间处于宕机状态。自行构建镜像使我们能够更快行动。

Cloud运行在Kubernetes上，其工作方式是协调。可以将其视为一个循环，将每个工作负载的期望状态与其当前状态进行比较，然后进行更改直到两者匹配。我们编写Kubernetes operator，将我们自己的逻辑添加到该循环中，其中一个app operator负责管理每个集群中的客户应用程序。

这为我们提供了一个放置补丁的位置。我们更新了app operator，使其在每个工作负载启动时将修补后的PHP二进制文件放入其中，而不是重建和重新部署客户镜像。Kubernetes工作负载是不可变的，因此operator会重启每个工作负载以应用更改，平台会吸收重启过程，使客户应用程序不会出现停机。

内置的节流器阻止operator一次性重启所有内容，从而保护下游系统，例如我们的真实数据源和计费管道。在此次推出中，我们将其速度提高了5倍，据我们估计，节流时间约为35分钟，而非约三小时。我们没有完全移除节流器，因为大量重启可能会使这些系统过载。

我们首先在开发和预发布环境中验证了该机制，然后在PHP版本公开之前，于11:17 UTC在我们密度最低的两个区域进行了金丝雀测试。第一波于14:31 UTC开始，从加拿大和东京启动，并先在一小部分上验证。从大约15:30 UTC开始，补丁在其余区域分批推出，以便我们在到达较大区域之前观察故障，并且重启不会同时发生。这次预发布在问题到达大多数客户之前就发现了问题，该机制现已成为我们的标准工具。到18:05 UTC，所有区域均达到100%。在此期间，我们暂停了Cloud上的新部署约三个半小时，从13:54到17:33 UTC。

规划比编码耗时更长。我们已经有构建模块。

所有时间均为UTC。标有~的时间根据通话录音重建，准确度约为10分钟。

PHP安全版本的预先通知在内部共享。

工程师计划在披露前进行静默修复，事件频道于20:56开启。

计划达成一致：在运行中的pod内修补PHP，而不是重建客户镜像。

Cloudflare托管防火墙规则启用，到10:24扩展至Forge和专用区域。

补丁机制的金丝雀测试在加拿大和东京开始。

Forge：因升级任务激增而性能下降。Envoyer：下线进行服务器升级。

Forge：部署失败，约48,000个任务排队。

Forge：我们告知客户队列已处理，部署应可正常工作。此为过早通知。

运行时补丁在所有Cloud区域达到100%。

Cloud事件解决。基础镜像已使用修补后的PHP和Node.js重建。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）