跳转到： 导航, 搜索

OSSN/OSSN-0092

使用配置作为 OSSA-2023-003 的短期缓解措施

总结

当存储系统取消映射卷，并且稍后在同一主机上将设备重新用于另一个卷时，可能会发生对卷的未经授权访问，因为主机上的 iSCSI 或 FC 连接中断。

受影响的服务 / 软件

  • cinder: <20.2.1, >=21.0.0 <21.2.1, ==22.0.0
  • glance_store: <3.0.1, >=4.0.0 <4.1.1, >=4.2.0 <4.3.1
  • nova: <25.1.2, >=26.0.0 <26.1.2, ==27.0.0
  • os-brick: <5.2.3, >=6.0.0 <6.1.1, >=6.2.0 <6.2.2

讨论

建议应用 OSSA-2023-003 中提供的修复 https://security.openstack.org/ossa/OSSA-2023-003.html，但更新 OpenStack 部署可能需要很长时间，需要适当的维护窗口，甚至可能需要验证发布过程才能进行部署，因此操作员可能更喜欢应用战术性配置更改到他们的云端，以防止有害操作，同时他们遵循标准化的流程。

在这种情况下，防止不安全分离的最快方法是双重的

  1. 确保 Nova 使用具有服务角色的用户来发送其令牌到 Cinder 的所有代表用户的请求，并且
  2. Cinder 通过策略保护易受攻击的 API。

建议的操作

如果部署使用 Cinder 作为后端存储的 Glance，为了使用这种替代的短期缓解措施，必须将 Glance 配置为对 Cinder 的所有请求使用单个具有服务角色的用户。如果您的部署 *不* 使用单个用户（也就是说，不是所有镜像卷都存储在单个项目，而是存储在每个用户的项目中），那么您就无法使用这种短期缓解策略，而必须应用前一节中描述的完整更改。

缓解步骤

A. 确保 Nova（如果适用，Glance）使用的用户具有服务角色

  • 在 Nova 中，这是在 nova.conf 的 [service_user] 部分配置的用户
  • 在 Glance 中，只有在使用 Cinder 作为 Glance 存储后端时，才会定义此用户。它在 glance.conf 的 [cinder] 部分中定义。


（如果您不使用 Cinder 作为 Glance 的后端，则无需为 Glance 定义服务用户）

B. 配置 Nova 以发送服务令牌 https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html

  • Glance 没有能力向 Cinder 发送服务令牌；相反，以下策略缓解依赖于在 glance.conf 的 [cinder]/cinder_store_user_name 选项中配置的用户在 Keystone 中被授予服务角色


C. 根据 https://docs.openstack.org/cinder/latest/configuration/block-storage/policy-config-HOWTO.html 配置 cinder 策略，使其具有以下内容

   "is_service": "role:service or service_user_id:<nova_service_uuid>"
   "volume:attachment_delete": "rule:xena_system_admin_or_project_member and rule:is_service"
   "volume_extension:volume_actions:terminate_connection": "rule:xena_system_admin_or_project_member and rule:is_service"
   "volume_extension:volume_actions:detach": "rule:xena_system_admin_or_project_member and rule:is_service"
   "volume_extension:volume_admin_actions:force_detach": "!"

笔记

  • 操作员应将 "<nova_service_uuid>" 替换为 nova.conf 的 [service_user] 部分中配置的用户的实际 UUID
  • 如果 Keystone 中标识服务的角色名称不是“service”，那么操作员也应相应地替换“role:service”，并对 cinder 配置文件中的 [keystone_authtoken]/service_token_roles 设置进行适当调整。
  • 可能不清楚为什么定义了四个策略目标。这是因为 Block Storage API v3 提供了四种不同的 API 调用，可以通过这些调用完成附件删除
    • DELETE /v3/attachments/{attachment_id}（引入于微版本 3.27，这是首选方法）
    • POST /v3/volumes/{volume_id}，请求体中包含 'os-detach' 操作
    • POST /v3/volumes/{volume_id}，请求体中包含 'os-terminate_connection' 操作
    • POST /v3/volumes/{volume_id}，请求体中包含 'os-force_detach' 操作

限制

这种仅配置方法的一个缺点是，虽然它可以防止前面描述的故意情况，但它不能防止意外情况。此外，它不够精细，无法区分可接受的最终用户 Block Storage API 附件删除请求和不安全的请求（Cinder 代码更改需要解决此问题）。出于这些原因，我们强调这只是一个短期缓解措施，我们建议尽快在您的部署中应用完整的修复。

警告

请注意，如果您部署此短期缓解措施，在应用完整的修复后，应回滚策略更改，否则最终用户将继续无法进行可接受的附件删除请求。

鸣谢

  • Jan Wasilewski, Atman
  • Gorka Eguileor, Red Hat

参考文献

作者

  • Brian Rosmaita, Red Hat
  • Dan Smith, Red Hat
  • Gorka Eguileor, Red Hat
  • Jeremy Stanley, OpenInfra Foundation
  • Nick Tait, Red Hat


此 OSSN：https://wiki.openstack.org/wiki/OSSN/OSSN-0092#Discussion

原始 Launchpad 错误：https://launchpad.net/bugs/2004555

邮件列表：[security-sig] 标签在 openstack-discuss@lists.openstack.org 上

OpenStack 安全项目：https://launchpad.net/~openstack-ossg

CVE：CVE-2023-2088

从 "https://wiki.openstack.org/w/index.php?title=OSSN/OSSN-0092&oldid=183149" 检索