共享网络漏洞披露与云平台安全加固实践

共享网络漏洞披露

本文分享了一家云安全公司的朋友在2024年1月向我们披露的一个安全漏洞的详细信息。

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

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

在生产中安全运行模型

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

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

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

漏洞详情

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

精心构建的模型容器可以窃听控制器与该平台其余部分之间的流量。由于控制器进程是受信任的，它使用密钥（API令牌等）与该平台内模型本应永远无法访问的系统进行通信。

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

1. 模型需要能够获得与控制器共享的网络命名空间的原始访问权限。
2. 控制器与该平台其余系统之间的通信需要是未加密的。

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

有关该漏洞的更多技术细节，我们推荐阅读该云安全公司关于此次披露的博客文章。

我们的响应

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

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

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

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

展望未来

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

我们将继续优先考虑该平台的安全。我们致力于从此类事件中学习，以改进我们的系统和实践。我们还将继续与该云安全公司等合作伙伴合作，识别并解决潜在的漏洞。我们理解，保持与您——我们的用户——的信任，取决于我们对安全的警惕。我们感谢您对我们的信任，并将继续努力保持该平台的安全。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）或者 我的个人博客 https://blog.qife122.com/
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

公众号二维码