Kubernetes 权限升级并可以访问 OpenShift 产品和服务中的敏感数据 - CVE-2018-1002105
此信息是否有帮助?
此信息是否有帮助?
在 kubernetes 中发现了一个安全漏洞,通过利用这个安全漏洞,可以使权限获得升级并可以访问 OpenShift 产品和服务中的敏感数据。 这个问题已被记录为 CVE-2018-1002105 ,它的安全影响级别被定为 Critical(严重)。
在所有 3.x 版本的 Red Hat OpenShift Container Platform 中,攻击者可以利用这个安全漏洞,对一个计算节点中使用一般用户权限运行的 pod (多个运行的容器实例)进行攻击来获得访问权限的升级。 升级后的权限可以包括对所有 secret、pod、环境变量、运行的 pod/容器进程,以及持久卷的访问。
此外,在 OpenShift Container Platform 版本 3.6 以及更高版本中,此漏洞允许集群管理员(cluster-admin)级别访问由聚合 API Server 托管的任何 API。 ‘metrics-service’ 和 ‘servicecatalog’ 都可能成为攻击的目标。通过服务目录(service catalog)的 Cluster-admin 级别的访问权限,一个原来没有相关权限的用户可以在任何命名空间以及任何节点上提升自己的访问权限来创建代理的服务。这将使一个攻击者可以在系统中部署恶意代码,或修改已存在的代理的服务。
在 OpenShift Dedicated 环境中,一个带有pod exec/attach/portforward权限的普通用户可以在运行这个节点的任何计算节点上获得 cluster-level 的管理权限。 这包括对所有运行负载的 exec权限、访问当前的 secret、日志等权限。
OpenShift API Server 包含在所有 OpenShift Container Platform 环境中,它用来处理集群所有的管理任务。在一般情况下,管理员和开发人员不会直接调用 API,而是使用 ‘oc’ 命令,‘oc’ 命令会调用 API 服务器。
API 服务器提供不同的功能,包括以下 oc 命令:
API 服务器作为一个在计算节点中运行的kubelet 的反向代理来实现相应的功能。当为了完成以上任何命令所需要实现的功能而连接到 kubelet 时,它会打开一个 websocket 连接以连接到管理员或开发人员原始调用中的 stdin、stdout 或 stderr。如需了解更多相关信息,请参阅 OpenShift Container Platform 3.11 架构指南的远程命令一节。
另外,API 服务器也在 带有 Kubernetes 的 API 集合(API Aggregation)系统中作为一个反向代理。API 集合可以使额外的 API 集成到核心 API 服务器中。上游 Kubernetes 把这些额外的 API 称为 API 扩展(API extensions)。通过使用 API 扩展,可以增加 OpenShift Container Platform 3 的功能。
红帽借此向报告这个安全漏洞的 Kubernetes 产品安全团队表示感谢。上游社区已确认这个安全漏洞的原始报告人为 Darren Shepherd。Upstream acknowledges Darren Shepherd as the original reporter.
视频:红帽对 Kubernetes Privilege Flaw Escallation 安全漏洞的介绍
博客: Kubernetes 权限升级漏洞:创新仍然需要 IT 安全
博客: 了解 Kubernetes 权限升级安全漏洞对 OpenShift 3 的影响
红帽产品安全团队已把 CVE-2018-1002105 的安全影响级别定为 Critical(严重)。
以下红帽产品版本会受到影响:
OpenShift API 服务器是一个用来处理 OpenShift Container Platform 3 API 请求的组件。在 OpenShift API 服务器的 “upgradeawarehandler” 类型中有一个漏洞。这个类型对计算节点以及其它通过 API 扩展添加的服务起到一个反向代理的作用。因为反向代理中存在的这个漏洞,当出现错误时反向代理不会关闭已连接到下游服务的连接。这将可以使用户通过调用 API 来升级自己的权限。
有两种方法来利用这个安全漏洞对 OpenShift Container Platform、OpenShift Online 或 OpenShift Dedicated 进行攻击。第一个方法涉及到对分配给普通用户的 pod exec、attach 或 portforward 权限的滥用;第二个方法是攻击 OpenShift Container Platform 3.6 以及更高版本中的 API 扩展功能(API 扩展用来提供服务目录(service catalog)并访问通过 API 扩展添加的其它服务)。
如果一个用户有任何 pod 的 pod exec/attach/portforward 权限,则其权限可以被升级到 cluster-admin,任何到一个计算节点 Kubelet api 的 API 调用都可以实现。对 Kubelet api 的 API 调用允许用户 exec 到任何运行在相同节点上的容器,包括可以对主机文件系统进行读/写操作的特权容器。
第二种攻击不需要任何特权,它会利用 OpenShift Container Platform、OpenShift Online 和 Dedicated 中 metrics-server’ 和 ‘servicecatalog’ 使用的 API 扩展的功能进行攻击。一个没有权限的用户可以获得部署在集群中的任何 API 扩展的 cluster-admin 权限,包括 ‘servicecatalog’。具有 ‘servicecatalog’ 的 Cluster-admin 访问权限将允许在任何命名空间以及任何节点上创建服务代理(service broker)
要检查安装的 OpenShift Container Platform 版本,发送一个到 API 服务器的 http 请求(请注意:URL 应该和 webconsole URL 相同):
curl https://openshift.example.com:8443/version/openshift | grep gitVersion
*端口值由具体配置决定
或者,如果您已使用 ‘oc’ 命令登录,则可以使用以下命令检查版本信息:
oc version
如果 OpenShift Container Platform 的版本低于以下列出的版本,则存在这个安全漏洞:
我们强烈建议,运行受影响版本的红帽产品的用户,在相关的勘误可用后,尽快进行更新。
OpenShift Online (Starter、Pro) 已进行了升级。 使用 OpenShift Dedicated 的用户,请联系您的相关支持人员来确认系统的状态以及相应的更新计划。
产品 | 软件包 | 公告/更新 |
---|---|---|
OpenShift Container Platform v3.11 | kubernetes | RHSA-2018:3537 |
OpenShift Container Platform v3.10 | kubernetes | RHSA-2018:3549 |
OpenShift Container Platform v3.9 | kubernetes | RHSA-2018:2908 |
OpenShift Container Platform v3.8 | kubernetes | RHSA-2018:3551 |
OpenShift Container Platform v3.7 | kubernetes | RHSA-2018:2906 |
OpenShift Container Platform v3.6 | kubernetes | RHSA-2018:3598 |
OpenShift Container Platform v3.5 | kubernetes | RHSA-2018:3624 |
OpenShift Container Platform v3.4 | kubernetes | RHSA-2018:3752 |
OpenShift Container Platform v3.3 | kubernetes | RHSA-2018:3754 |
OpenShift Container Platform v3.2 | kubernetes | RHSA-2018:3742 |
解决 OpenShift Container Platform 版本 3.2 或更高版本中这个问题的更新已提供。
已升级到最新版本的用户不需要执行额外的缓解操作。但是,如果没有进行升级,则推荐进行相关的缓解操作。
修改默认 admin 的设置,编辑带有 pod attach/exec/port-forward 权限的角色:
$oc edit clusterrole admin
添加一个值为 false 的 ‘rbac.authorization.kubernetes.io/autoupdate’ annotation,删除 pod attach/exec/portforward 权限。例如:
apiVersion: v1
kind:ClusterRole
metadata:
annotations:
openshift.io/description:A user that has edit rights within the project and can
change the project's membership.
creationTimestamp:2018-11-21T01:34:04Z
name: admin
resourceVersion:"148192"
selfLink: /oapi/v1/clusterroles/admin
uid:87dd0306-ed2d-11e8-9456-fa163e65ec84
rules:
- apiGroups:
- ""
attributeRestrictions: null
resources:
- pods
- pods/proxy
verbs:
对带有这些权限的 ‘edit’ 角色进行同样操作。
检查分配给用户的角色。在这里,admin 角色分配给了 quicklab 用户:
$ oc project myproj
$ oc adm policy who-can get pods/exec
Namespace: test
Verb: get
Resource: pods/exec
Users: quicklab
system:admin
system:serviceaccount:kube-system:generic-garbage-collector
system:serviceaccount:kube-system:namespace-controller
Groups: system:cluster-admins
system:masters
$ oc get rolebindings
NAME ROLE USERS GROUPS SERVICE ACCOUNTS SUBJECTS
admin /admin quicklab
system:deployers /system:deployer deployer
system:image-builders /system:image-builder builder
system:image-pullers /system:image-puller system:serviceaccounts:myproj
$ oc export clusterrole admin > admin-mitigate.yml
编辑 admin-mitigate.yml,添加一个值为 false 的 ‘rbac.authorization.kubernetes.io/autoupdate’ annotation,修改名称并删除 pod attach/exec/portforward 权限。例如:
apiVersion: v1
kind:ClusterRole
metadata:
annotations:
openshift.io/description:A user that has edit rights within the project and can
change the project's membership.
rbac.authorization.kubernetes.io/autoupdate: "false"
creationTimestamp: null
name: admin-mitigate
rules:
- apiGroups:
- ""
attributeRestrictions: null
resources:
- pods
- pods/proxy
verbs:
...
创建具有新配置的新角色:
$ cat admin-mitigate.yml | oc create -f -
将此角色分配给您不想让其拥有这些权限的用户:
$ oc adm policy remove-role-from-user admin quicklab
role "admin" removed: "quicklab"
$oc adm policy add-role-to-user admin-mitigate quicklab
role “admin-mitigate’”added: “quicklab”
在集群升级到可以解决这个问题的更新版本前,可以通过删除受影响的 API 扩展来缓解对 API 扩展的攻击。请仔细检查每个服务以确保删除它们不会导致关键功能的丧失。如果删除某些服务会影响到所需的功能,则需要采取其它方案,如对网络功能的使用进行限制。
获取需要禁用的服务列表:
$ oc get apiservices -o=custom-columns=NAME:.metadata.name,SERVICE:.spec.service,STATUS:.status.conditions[0].type,VALUE:.status.conditions[0].status | grep -v '<nil>'
例如,在 OCP 3.11 中服务可能包括:
名称 服务 状态 值 v1beta1.servicecatalog.k8s.io map[name:apiserver namespace:kube-service-catalog] Available True
禁用输出中列出的服务,例如:
$ oc delete svc apiserver -n kube-service-catalog
在这个例子中,重新启用 service-catalog 运行 openshift-service-catalog playbook。请参阅产品文档来获得重新启用其它服务的信息。
$ ansible-playbook [-i /path/to/inventory]
/usr/share/ansible/openshift-ansible/playbooks/openshift-service-catalog/config.yml
Comments