揭秘共享网络漏洞：从风险到防御的技术实践

共享网络漏洞披露

这篇帖子分享了某云安全公司的朋友在2024年1月向我们披露的一个安全漏洞的详细信息。

他们的研究结果表明，我们的基础设施可能允许恶意模型访问敏感数据。我们认真对待了他们的报告，并在与他们沟通后的24小时内（即他们最初披露后大约两周）部署了完整的缓解措施。此后，我们针对该问题部署了额外的缓解措施，现在对所有内部流量进行加密，并限制所有模型容器的特权网络访问。在我们的调查和缓解过程中，没有发现任何证据表明此漏洞曾被利用。

继续阅读以了解更多关于该漏洞的细节以及为保持平台安全所采取的步骤。

在生产中安全运行模型

在该平台，我们的工作是让您能轻松地使用机器学习模型构建出色的产品。我们努力确保您的模型可靠、快速，并在需要时自动扩展。同样重要但不太显眼的是，我们致力于将该平台打造为一个安全可靠、供您运行工作负载的平台。

我们业务的一大部分可归结为：获取用户（也就是您！）的代码，并在我们的生产环境中运行它。当我们这样做时，确保该代码仅拥有执行预期操作（如机器学习推理）的权限，而不能执行其他操作（如探查我们的网络、其他用户的模型等）至关重要。我们使用多层防御来确保这一点，包括但不限于：

• 容器化。模型被构建为开放容器（OCI）镜像，这为我们提供了一些保护，防止容器内的代码从容器中“逃逸”并在不应运行的地方执行。
• 网络隔离。在我们基础设施中运行的模型代码不允许探查整个网络。它只能与其正常运行所需的服务进行通信。
• 控制反转。当模型在我们的基础设施中运行时，它会从与其一起运行的服务接收明确的指令。这项服务（我们称之为“主管”）被信任可以与平台的其他部分通信，但模型本身则不被信任。

漏洞详情

某公司向我们披露的漏洞表明，虽然其中一些控制措施按预期工作，但其他措施则不然。虽然模型进程和“主管”进程彼此隔离，但它们共享一个网络（从技术上讲，它们共享一个网络命名空间）。

一个精心构造的模型容器可以窃听主管与该平台其他部分之间的流量。由于主管进程是被信任的，它使用密钥（如API令牌等）与该平台内的系统通信，而这些系统是模型永远不应访问的。

要使此漏洞可利用，需要满足两个条件：

1. 模型需要能够原始访问与主管共享的网络命名空间。
2. 主管与该平台其他系统之间的通信需要是未加密的。

在某公司向我们报告时，在该平台内部，这两个条件确实都成立。我们知道主管与该平台其他部分之间的流量需要加密，但我们认为容器的网络隔离为我们完成这项工作提供了更多时间。我们忽略了模型和主管容器共享网络命名空间这一点。

有关该漏洞的更多技术细节，建议阅读某公司关于此披露的博客文章。

响应措施

我们在收到某公司的披露后立即认真对待。我们首先决定解决未加密的内部网络流量问题。我们已经加密了所有通过公共互联网传输的该平台流量，并开始着手加密我们内部网络上的所有流量。

当我们在此过程中与某公司协商时，他们建议我们，如果可能，应该从模型容器中移除原始网络访问权限。不到24小时后，即2月2日，我们成功从所有模型容器中移除了 NET_ADMIN 和 NET_RAW 能力，以阻止对网络命名空间的特权访问。

移除网络能力足以缓解某公司披露的漏洞，但我们借此机会发展了我们的防御能力，并进一步提升了整体安全状况。自2月20日起，所有来自模型容器的内部流量都使用TLS进行加密。

在我们的调查和缓解过程中，没有发现任何证据表明除发现该漏洞的研究人员之外有其他人知晓此漏洞，也没有证据表明它被利用过。

展望未来

某公司拥有一支研究团队，他们不断关注云计算领域的新风险和新威胁。我们非常感谢某公司对此漏洞的协调披露，以及他们的合作帮助我们快速有效地解决了问题。

我们将继续优先考虑该平台的安全。我们致力于从此类事件中吸取教训，以改进我们的系统与实践。我们也将继续与某公司等合作伙伴协作，识别并解决潜在的漏洞。我们深知，与您——我们的用户——保持信任，取决于我们对安全的警惕。我们感谢您对我们的信任，并将继续努力保持该平台的安全。FINISHED