OpenShift 製品およびサービスにおける Kubernetes の権限エスカレーションと機密情報へのアクセス - CVE-2018-1002105

Public Date:
Updated -
Status
Ongoing
Impact
Critical

OpenShift 製品およびサービス内の機密情報へのアクセスと権限のエスカレーションが可能になる脆弱性が、kubernetes で検出されました。この問題には CVE-2018-1002105 が割り当てられ、セキュリティー上の影響は 重大 と評価されています。

OpenShift Container Platform のすべての 3.x バージョンで、通常のユーザー権限で Pod がスケジュールされているコンピュートノードで実行中の Pod (実行中の複数コンテナーインスタンス) が侵入される可能性があります。このアクセスには、シークレットや Pod、環境変数、実行中の Pod/コンテナープロセス、および永続ボリュームへのアクセスが含まれます。

また、OpenShift Container Platform バージョン 3.6 およびそれ以降では、この脆弱性により、集約 API サーバーにホストされているすべての API へのクラスター管理者レベルのアクセスが可能になります。‘metrics-service’ および ‘servicecatalog’ がターゲットに含まれます。サービスカタログへのクラスター管理者レベルのアクセスにより、権限のないユーザーの権限がエスカレートされ、任意の namespace および任意のノード上で仲介型サービスの作成が可能になります。このため、攻撃者は悪意のあるコードをデプロイしたり、既存の仲介型サービスを変更することができるようになります。

OpenShift Dedicated 環境では、pod exec/attach/portforward パーミッションを持つ通常のユーザーがその Pod を実行可能なコンピュートノード上でクラスターレベルの管理者権限を取得することが可能です。これには、実行中のすべてのワークロード、現行のすべてのシークレット、ログなどへの exec アクセスが含まれます。  

背景情報

OpenShift API サーバーはすべての OpenShift Container Platform インストールに含まれており、クラスターの管理タスクをすべて処理します。管理者および開発者は通常 API を直接呼び出すことはありませんが、この API サーバーを呼び出す ‘oc’ バイナリーを使用します。

この API サーバーは、以下の oc コマンドを含む各種機能を提供します。

  • oc exec
  • oc port-forward
  • oc rsh

これは、コンピュートノード上で実行中の kubelet にリバースプロキシーとして機能することで行われます。上記のコマンドを実行するために kubelet に接続する際には、websocket 接続が開かれ、stdin、stdout、または stderr が管理者または開発者の元のコールに接続されます。詳細については Remote Commands section of the OpenShift Container Platform 3.11 architecture guide を参照してください。

API サーバーは、Kubernetes の API 集約機能 実装時にもリバースプロキシーとして動作します。API 集約により、コア API サーバー に新たな API をインストールできるようになります。この追加 API については、アップストリームの Kubernetes は API 拡張として参照します。API 拡張により、アーキテクトは OpenShift Container Platform 3 の機能を拡張できます。

謝辞

Red Hat は、この問題を報告してくださった Kubernetes プロジェクトに感謝いたします。アップストリームでは、この脆弱性の最初の報告者である Darren Shepherd 氏に感謝いたします。

参考情報

Kubernetes Announce List

Video: Kubernetes Privilege Flaw Escallation Explained by Red Hat

ブログ記事: The Kubernetes privilege escalation flaw: Innovation still needs IT security expertise

ブログ記事: Understanding the critical Kubernetes privilege escalation flaw in OpenShift 3


影響を受ける製品

Red Hat Product セキュリティーチームは CVE-2018-1002105 のセキュリティー上の影響を 重大 と評価しています。

以下の Red Hat 製品のバージョンが影響を受けます。

  • Red Hat OpenShift Container Platform 3.x
  • Red Hat OpenShift Online
  • Red Hat OpenShift Dedicated

攻撃の詳細と影響

OpenShift API サーバーは、OpenShift Container Platform 3 の API リクエストを処理するコンポーネントです。OpenShift API サーバーには、コンピュートノードおよび API 拡張として追加されたその他のサービスに対してリバースプロキシーとして動作する ‘upgradeawarehandler’ タイプに脆弱性がありました。リバースプロキシーの不具合により、エラーが発生した際にダウンストリームサービスからの接続を閉じることができませんでした。このため、API コールを実行しているユーザーによる権限のエスカレーションが可能となっていました。

この脆弱性を使用して OpenShift Container Platform、OpenShift Online、または OpenShift Dedicated を攻撃する方法には、2 通りあります。1 つ目は、通常のユーザーに付与されている pod execattach、または portforward 権限を悪用するものです。2 つ目は、OpenShift Container Platform 3.6 およびそれ以降でサービスカタログと新たな機能へのアクセスを提供する API 拡張機能を使ったものです。

ある Pod でユーザーに pod exec/attach/portforward 権限がある場合は、この権限はクラスター管理者にエスカレートすることが可能で、コンピュートノード Kubelet API への API コールが実行できます。Kubelet API への API コールにより、ユーザーは権限のある Pod と同じノード上で実行中のコンテナーへ exec が可能になります。これには、ホストファイルシステムへの読み取り/書き込アクセスのある、権限のあるコンテナーが含まれます。

2 つ目の攻撃は権限を必要とせず、OpenShift Container Platform、OpenShift Online、または OpenShift Dedicated の ‘metrics-server’ および ‘servicecatalog’ が使用する API 拡張機能を悪用するものです。認証されていないユーザーが、‘servicecatalog’ を含むクラスターにデプロイされている任意の API 拡張へのクラスター管理者権限を取得できるようになります。クラスター管理者の ‘servicecatalog’ へのアクセスにより、任意の namespace や任意のノード上でサービスブローカーが作成できるようになります。 

脆弱性の診断

インストール済みの OpenShift Container Platform のバージョンを確認するには、以下のような http リクエストを API サーバーに送信します。(注: URL はウェブコンソール URL と同じものになります):

   curl https://openshift.example.com:8443/version/openshift | grep gitVersion

*ポートは設定によって異なります。

別の方法では、‘oc’ コマンドでログインしている場合、以下のコマンドでバージョンを確認できます。

   oc version

以下に記載のバージョンよりも古い OpenShift Container Platform は、脆弱性の影響を受けます。

  • v3.11.43-1
  • v3.10.72-1
  • v3.9.51-1
  • v3.8.44-1
  • v3.7.72-1
  • v3.6.173.0.140-1
  • v3.5.5.31.80-1
  • v3.4.1.44.57-1
  • v3.3.1.46.45-1
  • v3.2.1.34-2

対処方法

影響のあるバージョンの Red Hat 製品をご使用のお客様は、エラータが入手可能になり次第、該当製品を更新することが強く推奨されます。 

OpenShift Online (Starter、Pro) については修正済みです。OpenShift Dedicated をお使いのお客様は、サポート担当者に連絡して、フィクスについてのステータスおよびスケジュールをご確認ください。 

影響を受ける製品の更新

製品名パッケージアドバイザリー/更新
OpenShift Container Platform v3.11kubernetesRHSA-2018:3537
OpenShift Container Platform v3.10kubernetesRHSA-2018:3549
OpenShift Container Platform v3.9kubernetesRHSA-2018:2908
OpenShift Container Platform v3.8kubernetesRHSA-2018:3551
OpenShift Container Platform v3.7kubernetesRHSA-2018:2906
OpenShift Container Platform v3.6kubernetesRHSA-2018:3598
OpenShift Container Platform v3.5kubernetesRHSA-2018:3624
OpenShift Container Platform v3.4kubernetesRHSA-2018:3752
OpenShift Container Platform v3.3kubernetesRHSA-2018:3754
OpenShift Container Platform v3.2kubernetesRHSA-2018:3742


軽減策

OpenShift Container Platform バージョン 3.2 およびそれ以降については、不具合を軽減するフィクスが用意されています。   

最新バージョンに更新されたお客様は、下記の軽減策を適用する必要はありません。ただし、更新を適用できない場合は、軽減策の適用が推奨されます。 

pod exec/attach/port-forward 攻撃の軽減策 (OCP 3.2->3.11)

デフォルトの管理者に切り替え、以下のように 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’ ロールで同じ作業を繰り返します。

プロジェクト内の単一ユーザーの場合

ユーザーに割り当てられているロールを確認します。この例では、管理者ロールが 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

false の値で admin-mitigate.yml に ‘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 拡張攻撃の軽減策 (OCP 3.6 -> 3.11)

クラスターをパッチ適用済みバージョンにアップグレードするまでの間、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]AvailableTrue

出力にあるサービスを無効にします。例を示します。

$ 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

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In