安全公告和 CVE

Rancher 致力于向社区披露我们产品的安全问题。我们会针对已解决的问题发布安全公告和 CVE（Common Vulnerabilities and Exposures，通用漏洞披露）。Rancher GitHub 上的安全页面也会发布新的安全公告。

ID描述日期解决
CVE-2022-43759在 Rancher 2.5.0 至 2.5.16 和 2.6.0 至 2.6.9 中发现了一个问题，授权逻辑缺陷导致允许通过项目角色模板绑定 (PRTB) 和 -promoted 角色进行权限升级。2023 年 1 月 24 日Rancher v2.6.10 和 v2.5.17
CVE-2022-43758在 Rancher 2.5.0 至 2.5.16、2.6.0 至 2.6.9 和 2.7.0 版本中发现了一个问题，Rancher Git 包中存在命令注入漏洞。这个包使用 Rancher 容器镜像中可用的底层 Git 二进制文件来执行 Git 操作。特制的命令如果没有消除歧义，可能会在通过 Git 执行时造成混淆，导致在底层 Rancher 主机中进行命令注入。2023 年 1 月 24 日Rancher v2.7.1、v2.6.10 和 v2.5.17
CVE-2022-43757此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。我们发现 Rancher 之前发布的安全公告 CVE-2021-36782 没有解决某些敏感字段、Secret Token、加密密钥和 SSH 密钥，这些字段仍然以明文形式直接存储在 Kubernetes 上 Clusters 之类的对象。在 Rancher 中，集群中已认证的 Cluster Owners、Cluster Members、Project Owners 和 Project Members 可以看到公开的凭证。2023 年 1 月 24 日Rancher v2.7.1、v2.6.10 和 v2.5.17
CVE-2022-43755在 Rancher 2.6.9 和 2.7.0 之前的版本中发现了一个问题，即 cattle-cluster-agent 使用的 cattle-token Secret 是可预测的。重新生成 Token 之后，Token 的值依然相同。如果 Token 被泄露并且出于安全目的需要重新创建，这可能会造成严重的问题。Rancher 的 cattle-cluster-agent 使用 cattle-token 来连接到 Rancher 配置的下游集群 Kubernetes API。2023 年 1 月 24 日Rancher v2.7.1 和 v2.6.10
CVE-2022-21953在 Rancher 2.5.16、2.6.9 和 2.7.0 之前的版本中发现了一个问题。由于授权逻辑缺陷，任何下游集群上经过身份认证的用户都能在 Rancher local 集群中打开一个 shell pod (1)，而且对 kubectl 具有有限的访问权限 (2)。预期的行为是：除非明确授予权限，否则用户在 Rancher local 集群中没有这样的访问权限。2023 年 1 月 24 日Rancher v2.7.1、v2.6.10 和 v2.5.17
GHSA-c45c-39f6-6gw9此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。只会影响配置了或配置过外部身份认证提供程序的 Rancher 设置。我们发现，当在 Rancher 中配置外部身份认证提供程序然后将其禁用时，Rancher 生成的 Token 如果关联了通过现已禁用的身份认证提供程序授予访问权限的用户，那么 Token 不会被撤销。2023 年 1 月 24 日Rancher v2.7.1、v2.6.10 和 v2.5.17
CVE-2022-31247在 2.5.15（包括）到 2.6.6（包括）的 Rancher 版本中发现了一个问题，其中的授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 cluster-owner、manage cluster members、project-owner 和 manage project members）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。2022 年 8 月 18 日Rancher 2.6.7 和 Rancher 2.5.16
CVE-2021-367832.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 Cluster Owner、Cluster Member、Project Owner 和 Project Member 可以在 /v1/management.cattle.io.clusters、/v3/clusters 和 /k8s/clusters/local/apis/management.cattle.io/v3/clusters 端点上看到暴露的凭证。2022 年 8 月 18 日Rancher 2.6.7 和 Rancher 2.5.16
CVE-2021-36782在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 Cluster 等 Kubernetes 对象上（例如，cluster.management.cattle.io）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 Continum AG）和 Marco Stuurman（来自 Shock Media B.V.）发现并报告。2022 年 8 月 18 日Rancher 2.6.7 和 Rancher 2.5.16
CVE-2022-21951此漏洞仅影响通过 RKE 模板配置 Weave 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为网络加密创建密码。因此，集群中的网络流量将不加密发送。2022 年 5 月 24 日Rancher 2.6.5 和 Rancher 2.5.14
CVE-2021-36784在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新全局角色的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 restricted-admin 角色。2022 年 4 月 14 日Rancher 2.6.4 和 Rancher 2.5.13
CVE-2021-4200此漏洞仅影响在 Rancher 中使用 restricted-admin 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 cattle-global-data 命名空间中的 global-data 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 global-data 角色，因此这些用户都能写入模板 CatalogTemplates) 和模板版本 (CatalogTemplateVersions)。在 Rancher 中创建的新用户默认分配到 user 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。2022 年 4 月 14 日Rancher 2.6.4 和 Rancher 2.5.13
GHSA-wm2r-rp98-8pmh此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 Fleet 进行持续交付的客户。在 v1.5.11 之前版本中的 go-getter 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 v0.3.9 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。2022 年 4 月 14 日Rancher 2.6.4 和 Rancher 2.5.13
CVE-2021-36778在 Rancher 2.5.0 到 2.5.11 和 Rancher 2.6.0 到 2.6.2 中发现了一个漏洞，当从配置的私有仓库下载 Helm Chart 时，对同源策略的检查不足可能导致仓库凭证暴露给第三方提供商。仅当用户在 Rancher 的应用 & 应用市场 > 仓库中配置私有仓库的访问凭证时才会出现此问题。该问题由 Martin Andreas Ullrich 发现并报告。2022 年 4 月 14 日Rancher 2.6.3 和 Rancher 2.5.12
GHSA-hwm2-4ph6-w6m5在 Rancher 2.0 到 2.6.3 中发现了一个漏洞。Rancher 提供的 restricted Pod 安全策略（PSP）与 Kubernetes 提供的上游 restricted 策略有差别，因此 Rancher 的 PSP 将 runAsUser 设置为 runAsAny，而上游将 runAsUser 设置为 MustRunAsNonRoot。因此，即使 Rancher 的 restricted 策略是在项目或集群级别上强制执行的，容器也可以以任何用户身份运行，包括特权用户 (root)。2022 年 3 月 31 日Rancher 2.6.4
CVE-2021-36775在 Rancher 2.4.17、2.5.11 和 2.6.2 以及更高的版本中发现了一个漏洞。从项目中删除与某个组关联的项目角色后，能让这些使用者访问集群级别资源的绑定（Binding）不会被删除。导致问题的原因是不完整的授权逻辑检查。如果用户是受影响组中的成员，且能对 Rancher 进行认证访问，那么用户可以利用此漏洞访问他们不应该能访问的资源。暴露级别取决于受影响项目角色的原始权限级别。此漏洞仅影响在 Rancher 中基于组进行身份验证的客户。2022 年 3 月 31 日Rancher 2.6.3、Rancher 2.5.12 和 Rancher 2.4.18
CVE-2021-36776在 Rancher 2.5.0 到 2.5.9 中发现了一个漏洞，该漏洞允许经过认证用户通过 API 代理模拟集群上的任何用户，而无需知道被模拟用户的凭证。问题的原因是 API 代理在将请求发送到 Kubernetes API 之前未删除模拟标头。能认证访问 Rancher 的恶意用户可以冒充另一个在 Rancher 认证用户，从而对集群进行管理员级别的访问。2022 年 3 月 31 日Rancher 2.6.0 和 Rancher 2.5.10
CVE-2021-25318Rancher 2.0 的不可编辑版本发现了一个漏洞，在该版本中，无论资源的 API 组如何，用户都可以访问资源。例如，Rancher 应该允许用户访问 apps.catalog.cattle.io，但却错误地授予了对 apps.* 的访问权限。你可以在这里找到下游集群和 Rancher 管理集群中受影响的资源。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。2021 年 7 月 14 日Rancher 2.5.9 和 Rancher 2.4.16
CVE-2021-31999Rancher 2.0.0 的补丁版本发现了一个漏洞，恶意的 Rancher 用户可以针对托管集群的 Kubernetes API 的代理发起一个 API 请求，以获取他们无权访问的信息。这是通过在 Connection 标头中传递 “Impersonate-User” 或 “Impersonate-Group” 标头来实现的，然后代理会删除该标头。此时，请求不会模拟用户及其权限，而是会类似 Rancher management server 的请求，并错误地返回信息。该漏洞仅影响对集群具有一定级别权限的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。2021 年 7 月 14 日Rancher 2.5.9 和 Rancher 2.4.16
CVE-2021-25320Rancher 2.2.0 的补丁版本发现了一个漏洞，云凭证没有正确通过 Rancher API 验证。具体地说，是通过用于与云提供商通信的代理。任何登录并具有有效云提供商云凭证 ID 的 Rancher 用户都可以通过代理 API 调用该云提供商的 API，并且云凭证会被绑定。该漏洞仅影响有效的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。2021 年 7 月 14 日Rancher 2.5.9 和 Rancher 2.4.16
CVE-2021-25313所有 Rancher 2 版本上都发现了一个安全漏洞。使用浏览器访问 Rancher API 时，URL 没有正确转义，导致它容易受到 XSS 攻击。这些 API 端点的特制 URL 可能包括嵌入页面并在浏览器中执行的 JavaScript。暂时没有直接的缓解措施。请不要单击指向 Rancher Server 的不受信任链接。2021 年 3 月 2 日Rancher v2.5.6、Rancher v2.4.14 和 Rancher v2.3.11
CVE-2019-14435此漏洞让已验证的用户可以通过 Rancher 使用的系统服务容器可访问的 IP 提取私有数据。这包括但不限于云提供商元数据服务等服务。虽然 Rancher 允许用户为系统服务配置白名单域，但这个漏洞仍然可以被精心设计的 HTTP 请求利用。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 发现并报告。2019 年 8 月 5 日Rancher 2.2.7 和 Rancher 2.1.12
CVE-2019-14436该漏洞允许有权编辑角色绑定的项目成员为自己或其他用户分配集群级别的角色，从而授予他们对该集群的管理员访问权限。该问题由 Nokia 的 Michal Lipinski 发现并报告。2019 年 8 月 5 日Rancher 2.2.7 和 Rancher 2.1.12
CVE-2019-13209该漏洞被称为跨网页 Websocket 劫持攻击。该攻击允许攻击者以受害用户的角色/权限访问由 Rancher 管理的集群。它让受害用户登录到 Rancher Server，然后访问由攻击者托管的第三方站点。完成后，攻击者就可以使用受害用户的权限和身份对 Kubernetes API 执行命令。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 报告。2019 年 7 月 15 日Rancher 2.2.5、Rancher 2.1.11 和 Rancher 2.0.16
CVE-2019-12303项目所有者可以注入额外的 fluentd 日志配置，从而在 fluentd 容器内读取文件或执行任意命令。该问题由 Untamed Theory 的 Tyler Welton 报告。2019 年 6 月 5 日Rancher 2.2.4、Rancher 2.1.10 和 Rancher 2.0.15
CVE-2019-12274如果节点使用的内置主机驱动使用了文件路径选项，则节点可以读取 Rancher Server 容器内的任意文件，包括敏感文件。2019 年 6 月 5 日Rancher 2.2.4、Rancher 2.1.10 和 Rancher 2.0.15
CVE-2019-11202即使已被显式删除，Rancher 的默认管理员会在 Rancher 重启时重新创建。2019 年 4 月 16 日Rancher 2.2.2、Rancher 2.1.9 和 Rancher 2.0.14
CVE-2019-6287如果将项目成员添加到多个项目中，则成员还能继续访问被删除的项目中的命名空间。2019 年 1 月 29 日Rancher 2.1.6 和 Rancher 2.0.11
CVE-2018-20321任何有权访问 default 命名空间的项目成员都可以在 pod 中挂载 netes-default ServiceAccount，然后使用该 pod 对 Kubernetes 集群执行管理特权命令。2019 年 1 月 29 日Rancher 2.1.6 和 Rancher 2.0.11 - 对于这些版本或更高版本，我们有对应的回滚说明。