runCの深刻なセキュリティ上の欠陥により、DockerとKubernetesでroot権限の昇格が発生する可能性

Adam Iwaniuk氏とBorys Popławski氏が発見した、オープンソースソフトウェアrunCのセキュリティ上の欠陥が、2019年2月11日に公表され、CVE-2019-5736として報告されました。

DockerやKubernetesなど、複数のコンテナエンジンに影響するこの脆弱性は、コンテナエンジンの主要コンポーネントに存在します。コンテナが隔離された環境から脱出して実行元のホストサーバーにアクセスできるようになり、ほかのコンテナへのアクセスや、ホスト上でのroot権限の取得につながる可能性があります。

このセキュリティ問題は、2018年12月3日に報告された重大な脆弱性に続くものです。この脆弱性では、実行中のコンテナ内で任意のコマンドを実行できる攻撃に対して、Kubernetes APIのコンポーネントが脆弱であることが判明しました。

William Bowling氏は、概念実証（PoC）攻撃の実際の動作を示す動画をTwitterで共有しました。実行中のコンテナ内から、ホストサーバー上のrunCバイナリがバックドアを仕込んだバージョンに置き換えられています。

Iwaniuk氏とPopławski氏は本日、脆弱性の発見につながった研究の着想について詳しく述べたブログ記事（runCへの攻撃の詳細）を公開しました。

脆弱性について

この脆弱性はどのようにして発生するのでしょうか。Christian Brauner氏は、特権コンテナと非特権コンテナのセマンティクスを理解する重要性について、次のように述べています。

特権コンテナとは、ほかの条件が同じであれば、コンテナの内外でID 0の意味が同じになるコンテナのことです。LSM、seccomp、その他のセキュリティ機構を使っても、コンテナの内外でID 0の意味は変わらないため、「ほかの条件が同じであれば」としています。たとえば、ランタイム実装のバグによってコンテナから脱出されると、ホスト上のroot権限を奪われます。

非特権コンテナとは、コンテナ内のID 0とコンテナ外のID 0の意味が異なるコンテナのことです。たとえば、ランタイム実装のバグによってコンテナから脱出されても、通常はホスト上のroot権限を取得できません。これが可能になるのは、カーネルのユーザー名前空間の実装にバグがある場合に限られるはずです。

この脆弱性の深刻度が高く、影響範囲も広いのは、Dockerコンテナがデフォルトで特権コンテナとして実行されることに加え、runCコマンドラインバイナリの使用方法にも起因します。

Brauner氏の説明によると、Dockerなどのコンテナ技術の実装では、コンテナへのコマンドが指示されるたびにrunCバイナリが実行され、その後runCプロセスは終了します。そのため、悪意のあるコンテナがrunCバイナリを改変すると、それ以降のコンテナ操作では、改変されたrunCバイナリが実行されてしまいます。

これは、コンテナ操作の実行後も同様のプロセスが終了しないLXCの動作とは大きく異なります。

LXCは、コンテナのライフサイクル中に監視プロセス（コンテナごとに1つ）が終了しないため、悪意のあるイメージによる攻撃を受けません。カーネルは実行中のバイナリの変更を許可しないため、攻撃者がバイナリを改ざんすることはできません。コンテナが停止または強制終了されると、攻撃を実行しているタスクも、被害が発生する前に終了します。コンテナ内で最後に実行されていたプロセスが終了して初めて、監視プロセスも終了します。そのため、LXCのOCIテンプレートを使って特権OCIコンテナを実行しても、悪意のあるイメージによる脆弱性の影響は受けません。ただし、バイナリをアタッチする経路による攻撃は依然として可能です。

この脆弱性は、最小権限の原則とベストプラクティスを改めて思い起こさせます。弱点となる箇所が、より深刻な権限昇格や悪用の入り口にならないようにすることが重要です。

セキュリティ上の懸念と責任ある開示

コンテナ化技術の根本にあるのは、異なるアプリやサービスを分離することです。それが実現されていないとなれば、当然、警戒が必要です。

コンテナの世界では、ソフトウェアサプライチェーン攻撃は今に始まったことではなく、アプリケーションライブラリでもたびたび報じられています。2018年にThreatpostに掲載された記事では、Kromtech Security Centerの調査により、違法な暗号資産マイニングに使われていた悪意のあるコンテナが17個以上確認されたと報告されました。これらの悪意あるイメージは、Dockerイメージの公式パブリックレジストリであるDocker Hubでホストされ、その後削除されました。

runCの脆弱性に関する最新情報として、runCのメンテナーであり、SUSE LinuxのシニアソフトウェアエンジニアでもあるAleksa Sarai氏は昨日、別のLinuxコンテナ技術であるLXCも、異なる攻撃経路で前述のCVEの影響を受けると明らかにしました。

また、セキュリティ脆弱性に対するパッチが正常に適用されたかをテスト、検証するため、2月18日にエクスプロイトコードを公開する予定であることにも触れ、ユーザーに責任ある方法でパッチを適用するよう呼びかけました。

まだSnykをお試しでない方は、CLIを使ってローカルでテストを実行するか、ソースコードリポジトリを接続して自動スキャンと修正をお試しください。すでにSnykをご利用の方は、この脆弱性をデータベースで追跡していることをご確認ください。

Open Container Initiative（OCI）がレジストリにSECURITY.mdを追加し、セキュリティ問題の責任ある開示に関するガイドラインを研究者に提供していることを歓迎します。以前から、これに加えて、GitHubのセキュリティベストプラクティスで紹介している安全なソースコード管理のガイドラインも推奨してきました。

要点

• 信頼性が確認されていないコンテナのベースイメージは実行しない

• 常に最小権限の原則を適用し、非特権コンテナを選択して実行する

• オープンソースライブラリの脆弱性をスキャンして、このCVEに対して脆弱なままの未パッチサーバーがないか確認する