Amazon Linux 2: docker (ALASECS-2024-042)

critical Nessus プラグイン ID 206635

Language:

概要

リモートの Amazon Linux 2 ホストに、セキュリティ更新プログラムがありません。

説明

リモートホストにインストールされている docker のバージョンは、25.0.6-1より前のものです。したがって、ALAS2ECS-2024-042 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

最初のドメインとのサブドメインの一致または完全一致ではないドメインへの HTTP リダイレクトに従うと、http.Client が Authorization や Cookie などの機密性の高いヘッダーを転送しません。たとえば、foo.com から www.foo.com へのリダイレクトは Authorization ヘッダーを転送しますが、bar.com へのリダイレクトは転送しません。悪意を持って作成された HTTP リダイレクトにより、機密性の高いヘッダーが予期せず転送される可能性があります。(CVE-2023-45289)

protojson.Unmarshal 関数が、特定の形式の無効な JSON のマーシャリングを解除する際に無限ループに陥る可能性があります。この状態は、google.protobuf.Any 値を含むメッセージにアンマーシャリングしたとき、または UnmarshalOptions.DiscardUnknown オプションが設定されているときに発生する可能性があります。(CVE-2024-24786)

さまざまな Is メソッド (IsPrivate、IsLoopback など) が、IPv4 にマッピングされた IPv6 アドレスに対して期待通りに動作せず、従来の IPv4 では true を返すアドレスに対して false を返していました。
(CVE-2024-24790)

Moby は、Docker Engine、Docker Desktop、およびコンテナツールまたはランタイムのその他のディストリビューションの主要コンポーネントであるオープンソースのコンテナフレームワークです。Moby のネットワーク実装では、それぞれ独自の IP アドレス範囲とゲートウェイを持つ多数のネットワークを定義できます。この機能は、各ネットワークが異なるドライバー、パラメーターセット、および動作を持つことができるため、カスタムネットワークと呼ばれることがよくあります。ネットワークを作成するとき、ネットワークを _internal_ として指定するために「--internal」フラグが使用されます。
docker-compose.yml ファイルの「internal」属性は、ネットワークを _internal_ としてマークするために使用される可能性があり、他の API クライアントも「internal」パラメーターを指定する可能性があります。

ネットワークを持つコンテナが作成されると、一意のネットワークインターフェースと IP アドレスが割り当てられます。
ホストは、コンテナ IP との間の SNAT/DNAT を提供するゲートウェイ IP とともに、非内部ネットワークのルーターとして機能します。

内部ネットワーク上のコンテナは相互に通信できますが、ホストがアクセスできるネットワーク (LAN または WAN) とは通信できません。これは、デフォルトルートが設定されておらず、ファイヤーウォールルールがすべての送信トラフィックをドロップするように設定されているためです。ゲートウェイ IP アドレス (および適切に設定されたホストサービス) との通信が可能であり、ホストは任意のコンテナ IP と直接通信する可能性があります。

「dockerd」は、Linux カーネルのさまざまなネットワーク機能を設定してコンテナネットワークを有効にすることに加えて、一部のサービスをコンテナネットワークに直接提供します。これらのうちの主要なものは、リゾルバーとして機能し、サービス検出を可能にし、上流のリゾルバーからの名前の解決を可能にすることです。

コンテナに対応しない名前の DNS リクエストを受信すると、そのリクエストは設定済みの Upstream リゾルバーに転送されます。このリクエストは、コンテナのネットワーク名前空間から行われます。トラフィックのアクセスとルーティングのレベルは、リクエストがコンテナ自体によって行われた場合と同じです。

この設計の結果として、内部ネットワークにのみ接続されているコンテナは、コンテナ自体がそのネームサーバーと通信できないため、上流リゾルバーを使用して名前を解決できません。解決できるのは、内部ネットワークにもアタッチされているコンテナの名前のみです。

多くのシステムは、ローカルの転送 DNS リゾルバーを実行します。ホストとコンテナには別々のループバックデバイスがあるため、上記の設計の結果、コンテナはホストの構成されたリゾルバーからの名前を解決できなくなり、ホストループバックデバイスでこれらのアドレスに到達できないためです。このギャップを埋め、ローカルのフォワーディングリゾルバーがループバックアドレスで使用されている場合でもコンテナが適切に名前を解決できるようにするために、「dockerd」はこのシナリオを検出し、代わりにホストネームワークの名前空間から DNS リクエストを転送します。その後、ループバックリゾルバーは、期待通りに、設定されたアップストリームリゾルバーにリクエストを転送します。

「dockerd」は DNS リクエストをホストループバックデバイスに転送し、コンテナネットワークの名前空間の通常のルーティングセマンティクスを完全にバイパスするため、内部ネットワークが予期せずに DNS リクエストを外部ネームサーバーに転送する可能性があります。権限のあるネームサーバーをコントロールするドメインを登録することで、攻撃者は、侵害されたコンテナにデータを抽出させ、最終的にネームサーバーが応答するようにする DNS クエリでデータをエンコードする可能性があります。

Docker Desktop は常に RFC 1918 アドレスで内部リゾルバーを実行するため、Docker Desktop は影響を受けません。

Moby リリース 26.0.0、25.0.4、および 23.0.11 には、内部ネットワークからの DNS リクエストの転送を防ぐためのパッチが適用されています。回避策として、カスタムの Upstream アドレスを使用して内部ネットワークにのみアタッチするコンテナを実行してください。これにより、すべての Upstream DNS クエリがコンテナのネットワーク名前空間から解決されます。(CVE-2024-29018)

AWS は、CVE-2024-41110 を認識しています。これは、Amazon Linux で docker としてパッケージ化された Moby オープンソースプロジェクトに影響を与える問題です。Docker は、いくつかのオープンソースコンテナ管理システムのコンポーネントです。

この問題は、docker のデフォルト設定には影響しません。認証プラグインが有効な場合、docker デーモンへの特別に細工された API リクエストが認証プラグインに転送され、権限昇格などの意図しないアクションが引き起こされる可能性があります。承認プラグインの有効化は、通常とは異なる設定です。影響を受ける API エンドポイントは、デフォルト、標準、推奨のいずれの構成でもネットワークに公開されていません。デフォルトの EKS および ECS 設定は、API エンドポイントをネットワークに公開しません。ECS を使用している場合、Docker 認証プラグインの有効化はサポートされていません。最後に、docker は 1.24 より新しい EKS AMI にはインストールされていません。Docker は 1.24 以前の EKS にインストールされていますが、EKS は認証プラグインをサポートしていません。

この問題に対応する更新済みの docker パッケージが、Amazon Linux 2 (docker-20.10.25-1.amzn2.0.5 および docker-25.0.6-1.amzn2.0.1) および Amazon Linux 2023 (docker-25.0.6-1amzn2023.0.1) で利用可能です。AWS では、docker を使用しているお客様には、これらのバージョン以降にアップグレードすることを推奨しています。(CVE-2024-41110)

Tenable は、前述の記述ブロックをテスト済み製品のセキュリティアドバイザリから直接抽出しています。

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。