Fedora 39 : moby-engine (2023-b9c1d0e4c5)

high Nessus プラグイン ID 185286

Language:

概要

リモートの Fedora ホストに 1 つ以上のセキュリティ更新プログラムがありません。

説明

リモートの Fedora 39 ホストには、FEDORA-2023-b9c1d0e4c5 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

- 1.11.8、1.12.4、および 1.13.1 以前の HashiCorp Consul および Consul Enterprise は、内部 RPC エンドポイントの CSR で、複数の SAN URI 値をチェックしないため、特権アクセスを利用してサービスメッシュインテンションをバイパスすることが可能です。1.11.9、1.12.5、および 1.13.2 で修正されました。(CVE-2022-40716)

- 悪意のあるまたは大きな YAML ドキュメントの解析により、過剰な量の CPU またはメモリが消費される可能性があります。(CVE-2022-3064)

- containerd は、オープンソースのコンテナランタイムです。コンテナ内に補助グループが適切に設定されていないバージョン 1.6.18 および 1.5.18 より前の containerd にバグが見つかりました。攻撃者がコンテナに直接アクセスでき、補助グループのアクセス権を操作する場合、補助グループのアクセス権を使用して、プライマリグループの制限をバイパスし、機密情報へのアクセス権を取得したり、そのコンテナでコードを実行したりする可能性があります。containerd クライアントライブラリを使用するダウンストリームアプリケーションも影響を受ける可能性があります。このバグは、containerd v1.6.18 および v.1.5.18 で修正されました。この問題を解決するには、ユーザーがこれらのバージョンに更新して、コンテナを再作成する必要があります。
containerd のクライアントライブラリを使用するダウンストリームアプリケーションに依存するユーザーは、別のアドバイザリおよび指示についてそのアプリケーションをチェックする必要があります。回避策として、「USER $USERNAME」Dockerfile 命令が使用されていないことを確認してください。代わりに、コンテナエントリポイントを「ENTRYPOINT [su, -, user]」と同様の値に設定し、「su」が補助グループを適切に設定できるようにします。(CVE-2023-25173)

- BuildKit は、効率的で表現豊かに繰り返し可能な方法でソースコードをビルドアーティファクトに変換するためのツールキットです。影響を受けるバージョンでは、ユーザーが認証情報を含む Git URL を含むビルドリクエストを送信し、ビルドがそのビルドを記述した出所認証を作成する場合、これらの認証情報が Provenance 認証から表示される可能性があります。Git URL は次の 2 つの方法で渡されます。1) 認証情報を使用して URL から直接ビルドを呼び出す。2) クライアントがローカルソースからのビルドに関する追加のバージョンコントロールシステム (VCS) 情報のヒントパラメーターを送信する方法。通常、これは「.git/config」ファイルから元の URL を読み取ることを意味します。特定の条件下でビルドが実行されると、認証情報が BuildKit に渡された場合、その認証情報が Provenance 認証にアクセスできるすべてのユーザーに表示される可能性があります。
Provenance 認証および VCS 情報のヒントはバージョン v0.11.0 で追加されました。それ以前のバージョンは脆弱性の影響を受けません。v0.10 では、Git URL から直接ビルドを行うと、Provenance 認証の前身である「BuildInfo」構造で同じ URL が表示される可能性があります。以前のバージョンは脆弱性の影響を受けません。このバグは v0.11.4 で修正されました。ユーザーはアップグレードすることを推奨されています。アップグレードできないユーザーは、「BUILDX_GIT_INFO=0」を設定することで、VCS 情報ヒントを無効にできます。「buildctl」は、「.git」ディレクトリに基づいて VCS ヒントを設定しないため、値は「--opt」を使用して手動で渡す必要があります。(CVE-2023-26054)

- Consul および Consul Enterprise では、service: write 権限を持つ認証済みのユーザーが特定の状況化で引き起こすワークフローにより、Consul サーバーとクライアントエージェントがクラッシュする可能性があります。この脆弱性は、Consul 1.14.5 で修正されました。(CVE-2023-0845)

- Moby は、Docker Inc. によって開発されたオープンソースのコンテナフレームワークで、Docker、Mirantis Container Runtime、およびその他のさまざまなダウンストリームプロジェクトや製品として配布されています。moby/moby として開発された Moby デーモンコンポーネント (「dockerd」) は、一般に *Docker* と呼ばれています。Swarm Mode は、dockerd でデフォルトでコンパイルされ、デフォルトで提供され、ほとんどの主要な Moby ダウンストリームに存在します。シンプルなビルトインコンテナオーケストレーターであり、SwarmKit とサポートネットワークコードの組み合わせによって実装されます。オーバーレイネットワークドライバーは Swarm モードのコア機能であり、クラスター全体のコンテナとサービス間の通信を可能にする分離された仮想 LAN を提供します。このドライバーは、元のオーバーレイネットワークを識別する VXLAN ネットワーク ID (VNI) でフレームにタグを付ける UDP データグラムのリンク層 (イーサネット) フレームをカプセル化する VXLAN の実装/ユーザーです。さらに、オーバーレイネットワークドライバーは、デフォルトでオフの暗号化モードをオプションでサポートしています。これは、VXLAN パケットがノード間の信頼できないネットワークをトラバースする場合に特に役立ちます。暗号化オーバーレイネットワークは、IPsec カプセル化セキュリティペイロードプロトコルをトランスポートモードで使用して VXLAN データグラムをカプセル化することで機能します。IPSec カプセル化を展開することで、暗号化オーバーレイネットワークは、暗号化証明によるソース認証、チェックサムによるデータ整合性、暗号化による機密性といった追加のプロパティを取得します。暗号化されたオーバーレイネットワーク上にエンドポイントを設定する際、Moby は 3 つの iptables (Linux カーネルファイヤーウォール) ルールをインストールして、着信 IPSec と発信 IPSec の両方を強制します。これらのルールは、xt_u32 カーネルモジュールが提供する u32 iptables 拡張に依存しており、VXLAN パケットの VNI フィールドを直接フィルタリングします。これにより、他のオーバーレイネットワークや VXLAN の他のユーザーに干渉することなく、暗号化されたオーバーレイネットワークに IPSec の保証を強制できます。2 つの iptables ルールは、暗号化されたネットワークに対応する VNI で着信 VXLAN データグラムをフィルタリングし、暗号化されていないデータグラムを破棄します。これらのルールは、システム管理者によって以前に設定されたルールに従って、INPUT フィルターチェーンの末尾に追加されます。管理者が設定したルールは、Moby が暗号化されていない VXLAN データグラムを破棄するように設定したルールよりも優先されます。これにより、破棄されるべき暗号化されていないデータグラムが許容される可能性があります。任意のイーサネットフレームの注入により、サービス拒否攻撃が可能になる可能性があります。高度な攻撃者が、ステートフルファイヤーウォールによってブロックされるコンテナのアウトバウンドゲートウェイを介して、UDP または TCP 接続を確立したり、パケットをオーバーレイネットワークにスマグリングすることで、単純なインジェクションを超えて他の昇格を実行したりする可能性があります。パッチは、Moby リリース 23.0.3 および 20.10.24 で利用可能です。Mirantis Container Runtime の 20.10 リリースは異なる方法で番号が付けられているため、そのプラットフォームのユーザーは 20.10.16に更新する必要があります。いくつかの回避策が利用可能です。インターネット境界で着信トラフィックに対する VXLAN ポート (デフォルトでは UDP ポート 4789) を閉じて、すべての VXLAN パケットインジェクションを防止し、および / または「xt_u32」カーネルモジュールが Swarm クラスターのすべてのノードで利用可能であることを確認します。(CVE-2023-28840)

- Moby は、Docker Inc. によって開発されたオープンソースのコンテナフレームワークで、Docker、Mirantis Container Runtime、およびその他のさまざまなダウンストリームプロジェクトや製品として配布されています。moby/moby として開発された Moby デーモンコンポーネント (「dockerd」) は、一般に *Docker* と呼ばれています。Swarm Mode は、「dockerd」でデフォルトでコンパイルされ、デフォルトで提供され、ほとんどの主要な Moby ダウンストリームに存在します。これは、シンプルなビルトインコンテナオーケストレーターであり、SwarmKit とサポートネットワークコードの組み合わせによって実装されます。「オーバーレイ」ネットワークドライバーは Swarm モードのコア機能であり、クラスター全体のコンテナとサービス間の通信を可能にする分離された仮想 LAN を提供します。このドライバーは、元のオーバーレイネットワークを識別する VXLAN ネットワーク ID (VNI) でフレームにタグを付ける UDP データグラムのリンク層 (イーサネット) フレームをカプセル化する VXLAN の実装 / ユーザーです。さらに、オーバーレイネットワークドライバーは、デフォルトでオフの暗号化モードをオプションでサポートしています。これは、VXLAN パケットがノード間の信頼できないネットワークをトラバースする場合に特に役立ちます。
暗号化オーバーレイネットワークは、IPsec カプセル化セキュリティペイロードプロトコルをトランスポートモードで使用して VXLAN データグラムをカプセル化することで機能します。IPSec カプセル化を展開することで、暗号化オーバーレイネットワークは、暗号化証明によるソース認証、チェックサムによるデータ整合性、暗号化による機密性といった追加のプロパティを取得します。暗号化されたオーバーレイネットワーク上にエンドポイントを設定する際、Moby は 3 つの iptables (Linux カーネルファイヤーウォール) ルールをインストールして、着信 IPSec と発信 IPSec の両方を強制します。これらのルールは、「xt_u32」カーネルモジュールが提供する「u32」iptables 拡張に依存しており、VXLAN パケットの VNI フィールドを直接フィルタリングします。これにより、他のオーバーレイネットワークや VXLAN の他のユーザーに干渉することなく、暗号化されたオーバーレイネットワークに IPSec の保証を強制できます。iptables ルールは、IPsec カプセル化のための暗号化オーバーレイネットワークに対応する VNI を持つ発信 VXLAN データグラムを指定します。影響を受けるプラットフォームの暗号化オーバーレイネットワークは、暗号化されていないデータをサイレントに送信します。その結果、「オーバーレイ」ネットワークは機能しているように見え、トラフィックを想定通りに通過させますが、想定される機密性やデータの整合性は保証されません。ネットワーク上の信頼できる場所にいる攻撃者が、オーバーレイネットワーク上を移動するすべてのアプリケーショントラフィックを読み取ることが可能です。これにより、予期せずに機密情報やユーザーデータが漏洩する可能性があります。このように、多くのデータベースプロトコルや内部 API などが暗号化の第 2 レイヤーで保護されていないため、ユーザーは Swarm 暗号化オーバーレイネットワークを使用して機密性を提供する可能性があります。この脆弱性により、機密性はもはや保証されません。パッチは、Moby リリース 23.0.3 および 20.10.24 で利用可能です。Mirantis Container Runtime の 20.10 リリースは異なる方法で番号が付けられているため、そのプラットフォームのユーザーは 20.10.16に更新する必要があります。いくつかの回避策が利用可能です。インターネット境界で着信トラフィックに対する VXLAN ポート (デフォルトでは UDP ポート 4789) を閉じて、すべての VXLAN パケットインジェクションを防止し、および / または「xt_u32」カーネルモジュールが Swarm クラスターのすべてのノードで利用可能であることを確認します。
(CVE-2023-28841)

- Moby) は、Docker Inc. によって開発されたオープンソースのコンテナフレームワークで、Docker、Mirantis Container Runtime、およびその他のさまざまなダウンストリームプロジェクト / 製品として配布されています。moby/moby として開発された Moby デーモンコンポーネント (「dockerd」) は、一般に *Docker* と呼ばれています。Swarm Mode は、「dockerd」でデフォルトでコンパイルされ、デフォルトで提供され、ほとんどの主要な Moby ダウンストリームに存在します。これは、シンプルなビルトインコンテナオーケストレーターであり、SwarmKit とサポートネットワークコードの組み合わせによって実装されます。「オーバーレイ」ネットワークドライバーは Swarm モードのコア機能であり、クラスター全体のコンテナとサービス間の通信を可能にする分離された仮想 LAN を提供します。このドライバーは、元のオーバーレイネットワークを識別する VXLAN ネットワーク ID (VNI) でフレームにタグを付ける UDP データグラムのリンク層 (イーサネット) フレームをカプセル化する VXLAN の実装 / ユーザーです。さらに、オーバーレイネットワークドライバーは、デフォルトでオフの暗号化モードをオプションでサポートしています。これは、VXLAN パケットがノード間の信頼できないネットワークをトラバースする場合に特に役立ちます。
暗号化オーバーレイネットワークは、IPsec カプセル化セキュリティペイロードプロトコルをトランスポートモードで使用して VXLAN データグラムをカプセル化することで機能します。IPSec カプセル化を展開することで、暗号化オーバーレイネットワークは、暗号化証明によるソース認証、チェックサムによるデータ整合性、暗号化による機密性といった追加のプロパティを取得します。暗号化されたオーバーレイネットワーク上にエンドポイントを設定する際、Moby は 3 つの iptables (Linux カーネルファイヤーウォール) ルールをインストールして、着信 IPSec と発信 IPSec の両方を強制します。これらのルールは、「xt_u32」カーネルモジュールが提供する「u32」iptables 拡張に依存しており、VXLAN パケットの VNI フィールドを直接フィルタリングします。これにより、他のオーバーレイネットワークや VXLAN の他のユーザーに干渉することなく、暗号化されたオーバーレイネットワークに IPSec の保証を強制できます。「overlay」ドライバーは、コンテナがアタッチされたりデタッチされたりすると、各ノードの VXLAN ネットワークのカーネル設定を動的かつゆっくりと定義します。ルートと暗号化パラメーターは、ネットワークに参加している宛先ノードに対してのみ定義されます。暗号化されたオーバーレイネットワークが暗号化されていないパケットを受け入れることを防ぐ iptables ルールは、通信するピアが利用可能になるまで作成されません。暗号化オーバーレイネットワークは、暗号化オーバーレイネットワークの VNI でタグ付けされた平文の VXLAN データグラムを警告なしで受け入れます。その結果、任意のイーサネットフレームを VXLAN データグラムにカプセル化することで、暗号化されたオーバーレイネットワークに注入することができます。これは非常に深刻な影響を与える可能性があるため、より深い調査のために GHSA-vwm3-crmr-xfxw を参照する必要があります。パッチは、Moby リリース 23.0.3 および 20.10.24 で利用可能です。Mirantis Container Runtime の 20.10 リリースは異なる方法で番号が付けられているため、そのプラットフォームのユーザーは 20.10.16に更新する必要があります。いくつかの回避策が利用可能です。マルチノードクラスターでは、すべてのノードの暗号化された各オーバーレイネットワークに対してグローバルな「一時停止」コンテナを展開します。単一ノードクラスターでは、いかなる種類のオーバーレイネットワークも使用しないでください。ブリッジネットワークは、単一ノードで同じ接続性を提供し、マルチノード機能はありません。Swarm イングレス機能はオーバーレイネットワークを使用して実装されますが、「イングレス」モードではなく「ホスト」モードでポートを公開し (外部ロードバランサーの使用を許可)、「イングレス」ネットワークを削除することで無効にできます。暗号化されたオーバーレイネットワークが排他的に使用されている場合は、IPSec によって検証されていないトラフィックから UDP ポート 4789 をブロックします。
(CVE-2023-28842)

- HashiCorp Consul 1.8.1 から 1.11.8 まで、1.12.4 および 1.13.1 は、自動設定 RPC による JWT クレームアサーションでの補間および使用の前に、ノード名またはセグメント名を適切に検証しませんでした。1.11.9、1.12.5、および 1.13.2 で修正されました。(CVE-2021-41803)

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