The version of docker installed on the remote host is prior to 25.0.6-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2ECS-2024-042 advisory.

    2025-01-04: CVE-2024-36620 was added to this advisory.

    2025-01-04: CVE-2024-36623 was added to this advisory.

    When following an HTTP redirect to a domain which is not a subdomain match or exact match of the initial     domain, an http.Client does not forward sensitive headers such as Authorization or Cookie. For     example, a redirect from foo.com to www.foo.com will forward the Authorization header, but a redirect to     bar.com will not. A maliciously crafted HTTP redirect could cause sensitive headers to be unexpectedly     forwarded. (CVE-2023-45289)

    The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid     JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any     value, or when the UnmarshalOptions.DiscardUnknown option is set. (CVE-2024-24786)

    The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6     addresses, returning false for addresses which would return true in their traditional IPv4 forms.
    (CVE-2024-24790)

    Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and     other distributions of container tooling or runtimes. Moby's networking implementation allows for many     networks, each with their own IP address range and gateway, to be defined. This feature is frequently     referred to as custom networks, as each network can have a different driver, set of parameters and thus     behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_.
    The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and     other API clients may specify the `internal` parameter as well.

    When containers with networking are created, they are assigned unique network interfaces and IP addresses.
    The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from     container IPs.

    Containers on an internal network may communicate between each other, but are precluded from communicating     with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall     rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus     appropriately configured host services) is possible, and the host may communicate with any container IP     directly.

    In addition to configuring the Linux kernel's various networking features to enable container networking,     `dockerd` directly provides some services to container networks. Principal among these is serving as a     resolver, enabling service discovery, and resolution of names from an upstream resolver.

    When a DNS request for a name that does not correspond to a container is received, the request is     forwarded to the configured upstream resolver. This request is made from the container's network     namespace: the level of access and routing of traffic is the same as if the request was made by the     container itself.

    As a consequence of this design, containers solely attached to an internal network will be unable to     resolve names using the upstream resolver, as the container itself is unable to communicate with that     nameserver. Only the names of containers also attached to the internal network are able to be resolved.

    Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback     devices, a consequence of the design described above is that containers are unable to resolve names from     the host's configured resolver, as they cannot reach these addresses on the host loopback device. To     bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver     is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the     host namework namespace. The loopback resolver then forwards the requests to its configured upstream     resolvers, as expected.

    Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network     namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to     an external nameserver. By registering a domain for which they control the authoritative nameservers, an     attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that     will eventually be answered by their nameservers.

    Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.

    Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal     networks. As a workaround, run containers intended to be solely attached to internal networks with a     custom upstream address, which will force all upstream DNS queries to be resolved from the container's     network namespace. (CVE-2024-29018)

    moby v25.0.0 - v26.0.2 is vulnerable to NULL Pointer Dereference via daemon/images/image_history.go.
    (CVE-2024-36620)

    moby v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to     trigger multiple concurrent write operations resulting in data corruption or application crashes.
    (CVE-2024-36623)

    AWS is aware of CVE-2024-41110, an issue affecting the Moby open source project, packaged in Amazon Linux     as docker. Docker is a component of several open source container management systems.

    This issue does not affect the default configuration of docker. If an authorization plugin is enabled, a     specially-crafted API request to the docker daemon will be forwarded to the authorization plugin in a way     that could lead to unintended actions, such as privilege escalation. Enabling an authorization plugin is     an atypical configuration. The affected API endpoint is not exposed to the network in either the default,     typical, or recommended configurations. The default EKS and ECS configurations do not expose the API     endpoint to the network. Enabling a Docker authorization plugin is not supported when using ECS. Finally,     docker is not installed on EKS AMIs newer than 1.24. Although Docker is installed in EKS 1.24 and earlier,     EKS does not support authorization plugins.

    Updated docker packages addressing the issue are available for Amazon Linux 2 (docker-20.10.25-1.amzn2.0.5     and docker-25.0.6-1.amzn2.0.1) and for Amazon Linux 2023 (docker-25.0.6-1amzn2023.0.1). AWS recommends     that customers using docker upgrade to these or later versions. (CVE-2024-41110)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of docker installed on the remote host is prior to 25.0.6-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2DOCKER-2024-040 advisory.

    2025-01-04: CVE-2024-36620 was added to this advisory.

    2025-01-04: CVE-2024-36623 was added to this advisory.

    2024-08-27: CVE-2024-29018 was added to this advisory.

    2024-08-27: CVE-2024-24786 was added to this advisory.

    The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid     JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any     value, or when the UnmarshalOptions.DiscardUnknown option is set. (CVE-2024-24786)

    Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and     other distributions of container tooling or runtimes. Moby's networking implementation allows for many     networks, each with their own IP address range and gateway, to be defined. This feature is frequently     referred to as custom networks, as each network can have a different driver, set of parameters and thus     behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_.
    The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and     other API clients may specify the `internal` parameter as well.

    When containers with networking are created, they are assigned unique network interfaces and IP addresses.
    The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from     container IPs.

    Containers on an internal network may communicate between each other, but are precluded from communicating     with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall     rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus     appropriately configured host services) is possible, and the host may communicate with any container IP     directly.

    In addition to configuring the Linux kernel's various networking features to enable container networking,     `dockerd` directly provides some services to container networks. Principal among these is serving as a     resolver, enabling service discovery, and resolution of names from an upstream resolver.

    When a DNS request for a name that does not correspond to a container is received, the request is     forwarded to the configured upstream resolver. This request is made from the container's network     namespace: the level of access and routing of traffic is the same as if the request was made by the     container itself.

    As a consequence of this design, containers solely attached to an internal network will be unable to     resolve names using the upstream resolver, as the container itself is unable to communicate with that     nameserver. Only the names of containers also attached to the internal network are able to be resolved.

    Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback     devices, a consequence of the design described above is that containers are unable to resolve names from     the host's configured resolver, as they cannot reach these addresses on the host loopback device. To     bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver     is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the     host namework namespace. The loopback resolver then forwards the requests to its configured upstream     resolvers, as expected.

    Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network     namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to     an external nameserver. By registering a domain for which they control the authoritative nameservers, an     attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that     will eventually be answered by their nameservers.

    Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.

    Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal     networks. As a workaround, run containers intended to be solely attached to internal networks with a     custom upstream address, which will force all upstream DNS queries to be resolved from the container's     network namespace. (CVE-2024-29018)

    moby v25.0.0 - v26.0.2 is vulnerable to NULL Pointer Dereference via daemon/images/image_history.go.
    (CVE-2024-36620)

    moby v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to     trigger multiple concurrent write operations resulting in data corruption or application crashes.
    (CVE-2024-36623)

    AWS is aware of CVE-2024-41110, an issue affecting the Moby open source project, packaged in Amazon Linux     as docker. Docker is a component of several open source container management systems.

    This issue does not affect the default configuration of docker. If an authorization plugin is enabled, a     specially-crafted API request to the docker daemon will be forwarded to the authorization plugin in a way     that could lead to unintended actions, such as privilege escalation. Enabling an authorization plugin is     an atypical configuration. The affected API endpoint is not exposed to the network in either the default,     typical, or recommended configurations. The default EKS and ECS configurations do not expose the API     endpoint to the network. Enabling a Docker authorization plugin is not supported when using ECS. Finally,     docker is not installed on EKS AMIs newer than 1.24. Although Docker is installed in EKS 1.24 and earlier,     EKS does not support authorization plugins.

    Updated docker packages addressing the issue are available for Amazon Linux 2 (docker-20.10.25-1.amzn2.0.5     and docker-25.0.6-1.amzn2.0.1) and for Amazon Linux 2023 (docker-25.0.6-1amzn2023.0.1). AWS recommends     that customers using docker upgrade to these or later versions. (CVE-2024-41110)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of docker installed on the remote host is prior to 25.0.6-1. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2NITRO-ENCLAVES-2024-041 advisory.

    2025-01-04: CVE-2024-36620 was added to this advisory.

    2025-01-04: CVE-2024-36623 was added to this advisory.

    2024-08-27: CVE-2024-29018 was added to this advisory.

    2024-08-27: CVE-2024-24786 was added to this advisory.

    The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid     JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any     value, or when the UnmarshalOptions.DiscardUnknown option is set. (CVE-2024-24786)

    Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and     other distributions of container tooling or runtimes. Moby's networking implementation allows for many     networks, each with their own IP address range and gateway, to be defined. This feature is frequently     referred to as custom networks, as each network can have a different driver, set of parameters and thus     behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_.
    The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and     other API clients may specify the `internal` parameter as well.

    When containers with networking are created, they are assigned unique network interfaces and IP addresses.
    The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from     container IPs.

    Containers on an internal network may communicate between each other, but are precluded from communicating     with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall     rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus     appropriately configured host services) is possible, and the host may communicate with any container IP     directly.

    In addition to configuring the Linux kernel's various networking features to enable container networking,     `dockerd` directly provides some services to container networks. Principal among these is serving as a     resolver, enabling service discovery, and resolution of names from an upstream resolver.

    When a DNS request for a name that does not correspond to a container is received, the request is     forwarded to the configured upstream resolver. This request is made from the container's network     namespace: the level of access and routing of traffic is the same as if the request was made by the     container itself.

    As a consequence of this design, containers solely attached to an internal network will be unable to     resolve names using the upstream resolver, as the container itself is unable to communicate with that     nameserver. Only the names of containers also attached to the internal network are able to be resolved.

    Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback     devices, a consequence of the design described above is that containers are unable to resolve names from     the host's configured resolver, as they cannot reach these addresses on the host loopback device. To     bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver     is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the     host namework namespace. The loopback resolver then forwards the requests to its configured upstream     resolvers, as expected.

    Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network     namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to     an external nameserver. By registering a domain for which they control the authoritative nameservers, an     attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that     will eventually be answered by their nameservers.

    Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.

    Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal     networks. As a workaround, run containers intended to be solely attached to internal networks with a     custom upstream address, which will force all upstream DNS queries to be resolved from the container's     network namespace. (CVE-2024-29018)

    moby v25.0.0 - v26.0.2 is vulnerable to NULL Pointer Dereference via daemon/images/image_history.go.
    (CVE-2024-36620)

    moby v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to     trigger multiple concurrent write operations resulting in data corruption or application crashes.
    (CVE-2024-36623)

    AWS is aware of CVE-2024-41110, an issue affecting the Moby open source project, packaged in Amazon Linux     as docker. Docker is a component of several open source container management systems.

    This issue does not affect the default configuration of docker. If an authorization plugin is enabled, a     specially-crafted API request to the docker daemon will be forwarded to the authorization plugin in a way     that could lead to unintended actions, such as privilege escalation. Enabling an authorization plugin is     an atypical configuration. The affected API endpoint is not exposed to the network in either the default,     typical, or recommended configurations. The default EKS and ECS configurations do not expose the API     endpoint to the network. Enabling a Docker authorization plugin is not supported when using ECS. Finally,     docker is not installed on EKS AMIs newer than 1.24. Although Docker is installed in EKS 1.24 and earlier,     EKS does not support authorization plugins.

    Updated docker packages addressing the issue are available for Amazon Linux 2 (docker-20.10.25-1.amzn2.0.5     and docker-25.0.6-1.amzn2.0.1) and for Amazon Linux 2023 (docker-25.0.6-1amzn2023.0.1). AWS recommends     that customers using docker upgrade to these or later versions. (CVE-2024-41110)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

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

    2025-01-04: CVE-2024-36620 はこのアドバイザリに追加されました。

    2025-01-04: CVE-2024-36623 はこのアドバイザリに追加されました。

    2024-08-27: CVE-2024-29018 はこのアドバイザリに追加されました。

    2024-08-27: CVE-2024-24786 はこのアドバイザリに追加されました。

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

    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)

    moby v25.0.0 - v26.0.2 は、daemon/images/image_history.go を介した NULL ポインターデリファレンスに対して脆弱です。
    (CVE-2024-36620)

    moby v25.0.3 には、streamformatter パッケージに競合状態の脆弱性があります。これを利用すると、複数の同時書き込み操作がトリガーされ、データの破損やアプリケーションのクラッシュが引き起こされる可能性があります。
    (CVE-2024-36623)

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

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

    2025-01-04: CVE-2024-36620 はこのアドバイザリに追加されました。

    2025-01-04: CVE-2024-36623 はこのアドバイザリに追加されました。

    2024-08-27: CVE-2024-29018 はこのアドバイザリに追加されました。

    2024-08-27: CVE-2024-24786 はこのアドバイザリに追加されました。

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

    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)

    moby v25.0.0 - v26.0.2 は、daemon/images/image_history.go を介した NULL ポインターデリファレンスに対して脆弱です。
    (CVE-2024-36620)

    moby v25.0.3 には、streamformatter パッケージに競合状態の脆弱性があります。これを利用すると、複数の同時書き込み操作がトリガーされ、データの破損やアプリケーションのクラッシュが引き起こされる可能性があります。
    (CVE-2024-36623)

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

远程主机上安装的 docker 版本低于 25.0.6-1。因此，该 docker 受到 ALAS2NITRO-ENCLAVES-2024-041 公告中提及的多个漏洞的影响。

    2025-01-04：已将 CVE-2024-36620 添加到此公告中。

    2025-01-04：已将 CVE-2024-36623 添加到此公告中。

    2024-08-27：已将 CVE-2024-29018 添加到此公告中。

    2024-08-27：已将 CVE-2024-24786 添加到此公告中。

    protojson.Unmarshal 函数在取消封送某些形式的无效 JSON 时会进入无限循环。当解封为包含 google.protobuf.Any 值的消息，或当设置 UnmarshalOptions.DiscardUnknown 选项时，会发生此情况。(CVE-2024-24786)

    Moby 是一个开源容器框架，是 Docker Engine、Docker Desktop 及容器工具或运行时的其他发行版本的关键组件。Moby 的网络实现允许定义多个网络，每个网络都有自己的 IP 地址范围和网关。此功能通常称为自定义网络，因为每个网络都可以具有不同的驱动程序、参数集以及行为。创建网络时，“--internal”标记用于将网络指定为 _internal_。
    docker-compose.yml 文件中的“internal”属性也可用于将网络标记为 _internal_，且其他 API 客户端也可以指定“internal”参数。

    创建具有网络的容器时，系统会为其分配唯一的网络接口和 IP 地址。
    主机充当非内部网络的路由器，其网关 IP 提供与容器 IP 之间的 SNAT/DNAT。

    内部网络上的容器可以在彼此之间通信，但被阻止与主机可以访问的任何网络（LAN 或 WAN）通信，因为未配置默认路由，并且防火墙规则设置为终止所有传出流量。可以与网关 IP 地址（因此可适当配置主机服务）进行通信，且主机可直接与任何容器 IP 通信。

    除了配置 Linux 内核的多种网络功能以启用容器网络之外，“dockerd”还直接向容器网络提供某些服务。其中主要提供的服务为解析器，从而启用服务发现，并解析来自上游解析器的名称。

    收到针对名称与容器不符的 DNS 请求时，系统会将该请求转发到已配置的上游解析器。系统将此请求从容器的网络命名空间发出：流量的访问和路由级别与容器本身发出的请求相同。

    由于此设计，仅附加到内部网络的容器将无法使用上游解析器解析名称，因为容器本身无法与该名称服务器通信。只能解析同样附加到内部网络的容器的名称。

    许多系统运行本地转发 DNS 解析器。由于主机和容器具有单独的环回设备，上述设计的后果是容器无法从主机配置的解析器中解析名称，因为它们无法访问主机环回设备上的这些地址。为填补此漏洞，并允许容器正确解析名称（即使环回地址上使用了本地转发解析器），“dockerd”会检测此情况，并改为从主机名称工作命名空间转发 DNS 请求。然后，环回解析器按预期将请求转发到其配置的上游解析器。

    由于“dockerd”将 DNS 请求转发到主机环回设备从而完全绕过容器网络命名空间的正常路由语义，因此内部网络可能将 DNS 请求意外转发到外部名称服务器。攻击者可注册其控制权威名称服务器的域，方法是在最终将由其名称服务器应答的 DNS 查询中进行编码，从而安排遭入侵的容器泄露数据。

    Docker Desktop 不受影响，因为 Docker Desktop 始终在 RFC 1918 地址上运行内部解析器。

    已修补 Moby 版本 26.0.0、25.0.4 和 23.0.11，可防止转发来自内部网络的任何 DNS 请求。相关变通方案是，运行预期仅附加到具有自定义上游地址的内部网络的容器，这将强制从容器的网络命名空间中解析所有上游 DNS 查询。(CVE-2024-29018)

    moby v25.0.0 - v26.0.2 易受通过 daemon/images/image_history.go 造成的空指针取消引用影响。
    (CVE-2024-36620)

    moby v25.0.3 的 streamformatter 程序包中存在一个争用条件漏洞，可用于触发多个并发写入操作，导致数据损坏或应用程序崩溃。
    (CVE-2024-36623)

    AWS 发现 CVE-2024-41110，这是 Amazon Linux 的 docker 程序包中会影响 Moby 开源项目的问题。Docker 是包含多个开源容器管理系统的组件。

    此问题不影响 docker 的默认配置。如果启用了授权插件，则针对 docker 后台程序特别构建的 API 请求将被转发到授权插件，其转发方式可能导致特权提升等非预期操作。启用授权插件是一种非典型配置。受影响的 API 端点不会泄露给默认、典型或建议配置中的网络。默认 EKS 和 ECS 配置不会将 API 端点泄露给网络。如果使用的是 ECS，则不支持启用 docker 授权插件。最后，在高于 1.24 的 EKS AMI 上未安装 docker。尽管 EKS 1.24 及更早版本中已安装 docker，但 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

遠端主機上安裝的 docker 版本為要比 25.0.6-1 舊。因此，會受到 ALAS2DOCKER-2024-040 公告中所提及的多個弱點影響。

    2025-01-04 : 已將 CVE-2024-36620 新增至此公告。

    2025-01-04 : 已將 CVE-2024-36623 新增至此公告。

    2024-08-27：已將 CVE-2024-29018 新增至此公告。

    2024-08-27：已將 CVE-2024-24786 新增至此公告。

    在解除封送某些形式的無效 JSON 時，protojson.Unmarshal 函式會進入無限迴圈。將資料解除封送為含有 google.protobuf.Any 值的訊息時，或在設定 UnmarshalOptions.DiscardUnknown 選項時，便會發生此情形。(CVE-2024-24786)

    Moby 是一種開放原始碼容器架構，是 Docker Engine、Docker Desktop 和其他容器工具或執行階段發行版本的重要元件。Moby 的網路實作允許定義許多網路，每個網路可設定各自的 IP 位址範圍和閘道。此功能常稱為自訂網路，因為每個網路可有不同的驅動程式、參數集及行為。建立網路時，「--internal」標記用於將網路指定為 _internal_。
    docker-compose.yml 檔案中的「internal」屬性也可用來將網路標記為 _internal_，且其他 API 用戶端也可指定「internal」參數。

    建立具有網路功能的容器時，系統會指派唯一的網路介面和 IP 位址。
    主機作為非內部網路的路由器，其閘道 IP 可提供往來容器 IP 的 SNAT/DNAT。

    由於未設定預設路由，且防火牆規則設為中斷所有傳出流量，內部網路中的容器可相互通訊，但無法與主機可存取的網路 (LAN 或 WAN) 通訊。此外，也可與閘道 IP 位址 (及適當設定的主機服務) 進行通訊，且主機可直接與任何容器 IP 進行通訊。

    「dockerd」除了設定 Linux 核心的多種網路功能以啟用容器網路之外，還直接提供某些服務給容器網路。它主要是發揮解析器的功用，可啟用服務探索，以及透過上游解析器解析名稱。

    收到名稱與容器不相符的 DNS 要求時，系統會將要求轉送至已設定的上游解析器。此要求從容器的網路命名空間發出：存取層級和流量轉送都和直接從容器發出要求一樣。

    由於採用此設計，僅附加到內部網路的容器將無法透過上游解析器解析名稱，這是因為容器本身無法與該名稱伺服器通訊。只能解析也附加至內部網路的容器名稱。

    許多系統執行本機轉送 DNS 解析器。由於主機和所有容器都有獨立的回送裝置，上述設計會導致容器無法透過主機所設定的解析器解析名稱，這是因為它們無法到達主機回送裝置上的這些位址。為了解決此問題，並讓容器即便在將本機轉送解析器用於回送位址時也能妥善解析名稱，「dockerd」會偵測此情境，並改為從主機 namework 命名空間轉送 DNS 要求。然後，回送解析器會如預期將要求轉送至已設定的上游解析器。

    由於 `dockerd` 會將 DNS 要求轉送至主機回送裝置，完全忽略容器網路命名空間的正常轉送語意，因此內部網路可能會意外將 DNS 要求轉送至外部名稱伺服器。攻擊者可為所掌控的名稱伺服器註冊網域，藉此利用受到入侵的容器在 DNS 查詢中將資料進行編碼，最終透過名稱伺服器取得解碼的資料。

    Docker Desktop 一律會在 RFC 1918 位址上執行內部解析器，因此不會受到影響。

    Moby 26.0.0、25.0.4 和 23.0.11 版已經過修補，可避免從內部網路轉送 DNS 要求。您可以改為使用自訂上游位址執行預定單獨附加至內部網路的容器，這會強制從容器的網路命名空間解析所有上游 DNS 查詢 (CVE-2024-29018)。

    moby v25.0.0 - v26.0.2 容易受到透過 daemon/images/image_history.go 造成的 NULL 指標解除參照影響。
    (CVE-2024-36620)

    moby v25.0.3 在 streamformatter 套件中有一個爭用情形弱點，可用來觸發多個並行寫入作業，進而導致資料損毀或應用程式損毀。
    (CVE-2024-36623)

    AWS 已註意到 CVE-2024-41110，這是 Amazon Linux 的 docker 套件中會影響 Moby 開放原始碼專案的問題。Docker 是包含數個開放原始碼容器管理系統的元件。

    此問題不會影響 docker 伺服器的預設設定。如果啟用了授權外掛程式，則針對 docker 程序特製的 API 要求將被轉送至授權外掛程式，其轉送方式可能導致特權提升等非預期動作。啟用授權外掛程式是非典型設定。在預設、典型或建議的設定中，受影響的 API 端點不會洩漏給網路。預設的 EKS 和 ECS 設定不會將 API 端點洩漏給網路。使用 ECS 時，不支援啟用 docker 授權外掛程式。最後，docker 未安裝在比 1.24 新的 EKS AMI 上。雖然 docker 已安裝在 EKS 1.24 和更舊版本中，但 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

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

    2025-01-04: CVE-2024-36620 はこのアドバイザリに追加されました。

    2025-01-04: CVE-2024-36623 はこのアドバイザリに追加されました。

    最初のドメインとのサブドメインの一致または完全一致ではないドメインへの 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)

    moby v25.0.0 - v26.0.2 は、daemon/images/image_history.go を介した NULL ポインターデリファレンスに対して脆弱です。
    (CVE-2024-36620)

    moby v25.0.3 には、streamformatter パッケージに競合状態の脆弱性があります。これを利用すると、複数の同時書き込み操作がトリガーされ、データの破損やアプリケーションのクラッシュが引き起こされる可能性があります。
    (CVE-2024-36623)

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

远程主机上安装的 docker 版本低于 25.0.6-1。因此，该软件受到 ALAS2ECS-2024-042 公告中提及的多个漏洞影响。

    2025-01-04：已将 CVE-2024-36620 添加到此公告中。

    2025-01-04：已将 CVE-2024-36623 添加到此公告中。

    如果 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 提供与容器 IP 之间的 SNAT/DNAT。

    内部网络上的容器可以在彼此之间通信，但被阻止与主机可以访问的任何网络（LAN 或 WAN）通信，因为未配置默认路由，并且防火墙规则设置为终止所有传出流量。可以与网关 IP 地址（因此可适当配置主机服务）进行通信，且主机可直接与任何容器 IP 通信。

    除了配置 Linux 内核的多种网络功能以启用容器网络之外，“dockerd”还直接向容器网络提供某些服务。其中主要提供的服务为解析器，从而启用服务发现，并解析来自上游解析器的名称。

    收到针对名称与容器不符的 DNS 请求时，系统会将该请求转发到已配置的上游解析器。系统将此请求从容器的网络命名空间发出：流量的访问和路由级别与容器本身发出的请求相同。

    由于此设计，仅附加到内部网络的容器将无法使用上游解析器解析名称，因为容器本身无法与该名称服务器通信。只能解析同样附加到内部网络的容器的名称。

    许多系统运行本地转发 DNS 解析器。由于主机和容器具有单独的环回设备，上述设计的后果是容器无法从主机配置的解析器中解析名称，因为它们无法访问主机环回设备上的这些地址。为填补此漏洞，并允许容器正确解析名称（即使环回地址上使用了本地转发解析器），“dockerd”会检测此情况，并改为从主机名称工作命名空间转发 DNS 请求。然后，环回解析器按预期将请求转发到其配置的上游解析器。

    由于“dockerd”将 DNS 请求转发到主机环回设备从而完全绕过容器网络命名空间的正常路由语义，因此内部网络可能将 DNS 请求意外转发到外部名称服务器。攻击者可注册其控制权威名称服务器的域，方法是在最终将由其名称服务器应答的 DNS 查询中进行编码，从而安排遭入侵的容器泄露数据。

    Docker Desktop 不受影响，因为 Docker Desktop 始终在 RFC 1918 地址上运行内部解析器。

    已修补 Moby 版本 26.0.0、25.0.4 和 23.0.11，可防止转发来自内部网络的任何 DNS 请求。相关变通方案是，运行预期仅附加到具有自定义上游地址的内部网络的容器，这将强制从容器的网络命名空间中解析所有上游 DNS 查询。(CVE-2024-29018)

    moby v25.0.0 - v26.0.2 易受通过 daemon/images/image_history.go 造成的空指针取消引用影响。
    (CVE-2024-36620)

    moby v25.0.3 的 streamformatter 程序包中存在一个争用条件漏洞，可用于触发多个并发写入操作，导致数据损坏或应用程序崩溃。
    (CVE-2024-36623)

    AWS 发现 CVE-2024-41110，这是 Amazon Linux 的 docker 程序包中会影响 Moby 开源项目的问题。Docker 是包含多个开源容器管理系统的组件。

    此问题不影响 docker 的默认配置。如果启用了授权插件，则针对 docker 后台程序特别构建的 API 请求将被转发到授权插件，其转发方式可能导致特权提升等非预期操作。启用授权插件是一种非典型配置。受影响的 API 端点不会泄露给默认、典型或建议配置中的网络。默认 EKS 和 ECS 配置不会将 API 端点泄露给网络。如果使用的是 ECS，则不支持启用 docker 授权插件。最后，在高于 1.24 的 EKS AMI 上未安装 docker。尽管 EKS 1.24 及更早版本中已安装 docker，但 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机上安装的 docker 版本低于 25.0.6-1。因此，该软件受到 ALAS2DOCKER-2024-040 公告中提及的多个漏洞影响。

    2025-01-04：已将 CVE-2024-36620 添加到此公告中。

    2025-01-04：已将 CVE-2024-36623 添加到此公告中。

    2024-08-27：已将 CVE-2024-29018 添加到此公告中。

    2024-08-27：已将 CVE-2024-24786 添加到此公告中。

    protojson.Unmarshal 函数在取消封送某些形式的无效 JSON 时会进入无限循环。当解封为包含 google.protobuf.Any 值的消息，或当设置 UnmarshalOptions.DiscardUnknown 选项时，会发生此情况。(CVE-2024-24786)

    Moby 是一个开源容器框架，是 Docker Engine、Docker Desktop 及容器工具或运行时的其他发行版本的关键组件。Moby 的网络实现允许定义多个网络，每个网络都有自己的 IP 地址范围和网关。此功能通常称为自定义网络，因为每个网络都可以具有不同的驱动程序、参数集以及行为。创建网络时，“--internal”标记用于将网络指定为 _internal_。
    docker-compose.yml 文件中的“internal”属性也可用于将网络标记为 _internal_，且其他 API 客户端也可以指定“internal”参数。

    创建具有网络的容器时，系统会为其分配唯一的网络接口和 IP 地址。
    主机充当非内部网络的路由器，其网关 IP 提供与容器 IP 之间的 SNAT/DNAT。

    内部网络上的容器可以在彼此之间通信，但被阻止与主机可以访问的任何网络（LAN 或 WAN）通信，因为未配置默认路由，并且防火墙规则设置为终止所有传出流量。可以与网关 IP 地址（因此可适当配置主机服务）进行通信，且主机可直接与任何容器 IP 通信。

    除了配置 Linux 内核的多种网络功能以启用容器网络之外，“dockerd”还直接向容器网络提供某些服务。其中主要提供的服务为解析器，从而启用服务发现，并解析来自上游解析器的名称。

    收到针对名称与容器不符的 DNS 请求时，系统会将该请求转发到已配置的上游解析器。系统将此请求从容器的网络命名空间发出：流量的访问和路由级别与容器本身发出的请求相同。

    由于此设计，仅附加到内部网络的容器将无法使用上游解析器解析名称，因为容器本身无法与该名称服务器通信。只能解析同样附加到内部网络的容器的名称。

    许多系统运行本地转发 DNS 解析器。由于主机和容器具有单独的环回设备，上述设计的后果是容器无法从主机配置的解析器中解析名称，因为它们无法访问主机环回设备上的这些地址。为填补此漏洞，并允许容器正确解析名称（即使环回地址上使用了本地转发解析器），“dockerd”会检测此情况，并改为从主机名称工作命名空间转发 DNS 请求。然后，环回解析器按预期将请求转发到其配置的上游解析器。

    由于“dockerd”将 DNS 请求转发到主机环回设备从而完全绕过容器网络命名空间的正常路由语义，因此内部网络可能将 DNS 请求意外转发到外部名称服务器。攻击者可注册其控制权威名称服务器的域，方法是在最终将由其名称服务器应答的 DNS 查询中进行编码，从而安排遭入侵的容器泄露数据。

    Docker Desktop 不受影响，因为 Docker Desktop 始终在 RFC 1918 地址上运行内部解析器。

    已修补 Moby 版本 26.0.0、25.0.4 和 23.0.11，可防止转发来自内部网络的任何 DNS 请求。相关变通方案是，运行预期仅附加到具有自定义上游地址的内部网络的容器，这将强制从容器的网络命名空间中解析所有上游 DNS 查询。(CVE-2024-29018)

    moby v25.0.0 - v26.0.2 易受通过 daemon/images/image_history.go 造成的空指针取消引用影响。
    (CVE-2024-36620)

    moby v25.0.3 的 streamformatter 程序包中存在一个争用条件漏洞，可用于触发多个并发写入操作，导致数据损坏或应用程序崩溃。
    (CVE-2024-36623)

    AWS 发现 CVE-2024-41110，这是 Amazon Linux 的 docker 程序包中会影响 Moby 开源项目的问题。Docker 是包含多个开源容器管理系统的组件。

    此问题不影响 docker 的默认配置。如果启用了授权插件，则针对 docker 后台程序特别构建的 API 请求将被转发到授权插件，其转发方式可能导致特权提升等非预期操作。启用授权插件是一种非典型配置。受影响的 API 端点不会泄露给默认、典型或建议配置中的网络。默认 EKS 和 ECS 配置不会将 API 端点泄露给网络。如果使用的是 ECS，则不支持启用 docker 授权插件。最后，在高于 1.24 的 EKS AMI 上未安装 docker。尽管 EKS 1.24 及更早版本中已安装 docker，但 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 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

遠端主機上安裝的 docker 版本為要比 25.0.6-1 舊。因此，會受到 ALAS2NITRO-ENCLAVES-2024-041 公告中所提及的多個弱點影響。

    2025-01-04 : 已將 CVE-2024-36620 新增至此公告。

    2025-01-04 : 已將 CVE-2024-36623 新增至此公告。

    2024-08-27：已將 CVE-2024-29018 新增至此公告。

    2024-08-27：已將 CVE-2024-24786 新增至此公告。

    在解除封送某些形式的無效 JSON 時，protojson.Unmarshal 函式會進入無限迴圈。將資料解除封送為含有 google.protobuf.Any 值的訊息時，或在設定 UnmarshalOptions.DiscardUnknown 選項時，便會發生此情形。(CVE-2024-24786)

    Moby 是一種開放原始碼容器架構，是 Docker Engine、Docker Desktop 和其他容器工具或執行階段發行版本的重要元件。Moby 的網路實作允許定義許多網路，每個網路可設定各自的 IP 位址範圍和閘道。此功能常稱為自訂網路，因為每個網路可有不同的驅動程式、參數集及行為。建立網路時，「--internal」標記用於將網路指定為 _internal_。
    docker-compose.yml 檔案中的「internal」屬性也可用來將網路標記為 _internal_，且其他 API 用戶端也可指定「internal」參數。

    建立具有網路功能的容器時，系統會指派唯一的網路介面和 IP 位址。
    主機作為非內部網路的路由器，其閘道 IP 可提供往來容器 IP 的 SNAT/DNAT。

    由於未設定預設路由，且防火牆規則設為中斷所有傳出流量，內部網路中的容器可相互通訊，但無法與主機可存取的網路 (LAN 或 WAN) 通訊。此外，也可與閘道 IP 位址 (及適當設定的主機服務) 進行通訊，且主機可直接與任何容器 IP 進行通訊。

    「dockerd」除了設定 Linux 核心的多種網路功能以啟用容器網路之外，還直接提供某些服務給容器網路。它主要是發揮解析器的功用，可啟用服務探索，以及透過上游解析器解析名稱。

    收到名稱與容器不相符的 DNS 要求時，系統會將要求轉送至已設定的上游解析器。此要求從容器的網路命名空間發出：存取層級和流量轉送都和直接從容器發出要求一樣。

    由於採用此設計，僅附加到內部網路的容器將無法透過上游解析器解析名稱，這是因為容器本身無法與該名稱伺服器通訊。只能解析也附加至內部網路的容器名稱。

    許多系統執行本機轉送 DNS 解析器。由於主機和所有容器都有獨立的回送裝置，上述設計會導致容器無法透過主機所設定的解析器解析名稱，這是因為它們無法到達主機回送裝置上的這些位址。為了解決此問題，並讓容器即便在將本機轉送解析器用於回送位址時也能妥善解析名稱，「dockerd」會偵測此情境，並改為從主機 namework 命名空間轉送 DNS 要求。然後，回送解析器會如預期將要求轉送至已設定的上游解析器。

    由於 `dockerd` 會將 DNS 要求轉送至主機回送裝置，完全忽略容器網路命名空間的正常轉送語意，因此內部網路可能會意外將 DNS 要求轉送至外部名稱伺服器。攻擊者可為所掌控的名稱伺服器註冊網域，藉此利用受到入侵的容器在 DNS 查詢中將資料進行編碼，最終透過名稱伺服器取得解碼的資料。

    Docker Desktop 一律會在 RFC 1918 位址上執行內部解析器，因此不會受到影響。

    Moby 26.0.0、25.0.4 和 23.0.11 版已經過修補，可避免從內部網路轉送 DNS 要求。您可以改為使用自訂上游位址執行預定單獨附加至內部網路的容器，這會強制從容器的網路命名空間解析所有上游 DNS 查詢 (CVE-2024-29018)。

    moby v25.0.0 - v26.0.2 容易受到透過 daemon/images/image_history.go 造成的 NULL 指標解除參照影響。
    (CVE-2024-36620)

    moby v25.0.3 在 streamformatter 套件中有一個爭用情形弱點，可用來觸發多個並行寫入作業，進而導致資料損毀或應用程式損毀。
    (CVE-2024-36623)

    AWS 已註意到 CVE-2024-41110，這是 Amazon Linux 的 docker 套件中會影響 Moby 開放原始碼專案的問題。Docker 是包含數個開放原始碼容器管理系統的元件。

    此問題不會影響 docker 伺服器的預設設定。如果啟用了授權外掛程式，則針對 docker 程序特製的 API 要求將被轉送至授權外掛程式，其轉送方式可能導致特權提升等非預期動作。啟用授權外掛程式是非典型設定。在預設、典型或建議的設定中，受影響的 API 端點不會洩漏給網路。預設的 EKS 和 ECS 設定不會將 API 端點洩漏給網路。使用 ECS 時，不支援啟用 docker 授權外掛程式。最後，docker 未安裝在比 1.24 新的 EKS AMI 上。雖然 docker 已安裝在 EKS 1.24 和更舊版本中，但 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 docker 版本為要比 25.0.6-1 舊。因此，會受到 ALAS2ECS-2024-042 公告中所提及的多個弱點影響。

    2025-01-04 : 已將 CVE-2024-36620 新增至此公告。

    2025-01-04 : 已將 CVE-2024-36623 新增至此公告。

    跟隨 HTTP 重新導向至不符合子網域的網域或不完全符合初始網域的網域時，http.Client 不會轉送敏感標頭，例如 Authorization 或 Cookie。例如，從 foo.com 重新導向至 www.foo.com 會轉送授權標頭，但重新導向至 bar.com 則不會。惡意的特質 HTTP 重新導向可導致意外轉送敏感標頭。(CVE-2023-45289)

    在解除封送某些形式的無效 JSON 時，protojson.Unmarshal 函式會進入無限迴圈。將資料解除封送為含有 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 可提供往來容器 IP 的 SNAT/DNAT。

    由於未設定預設路由，且防火牆規則設為中斷所有傳出流量，內部網路中的容器可相互通訊，但無法與主機可存取的網路 (LAN 或 WAN) 通訊。此外，也可與閘道 IP 位址 (及適當設定的主機服務) 進行通訊，且主機可直接與任何容器 IP 進行通訊。

    「dockerd」除了設定 Linux 核心的多種網路功能以啟用容器網路之外，還直接提供某些服務給容器網路。它主要是發揮解析器的功用，可啟用服務探索，以及透過上游解析器解析名稱。

    收到名稱與容器不相符的 DNS 要求時，系統會將要求轉送至已設定的上游解析器。此要求從容器的網路命名空間發出：存取層級和流量轉送都和直接從容器發出要求一樣。

    由於採用此設計，僅附加到內部網路的容器將無法透過上游解析器解析名稱，這是因為容器本身無法與該名稱伺服器通訊。只能解析也附加至內部網路的容器名稱。

    許多系統執行本機轉送 DNS 解析器。由於主機和所有容器都有獨立的回送裝置，上述設計會導致容器無法透過主機所設定的解析器解析名稱，這是因為它們無法到達主機回送裝置上的這些位址。為了解決此問題，並讓容器即便在將本機轉送解析器用於回送位址時也能妥善解析名稱，「dockerd」會偵測此情境，並改為從主機 namework 命名空間轉送 DNS 要求。然後，回送解析器會如預期將要求轉送至已設定的上游解析器。

    由於 `dockerd` 會將 DNS 要求轉送至主機回送裝置，完全忽略容器網路命名空間的正常轉送語意，因此內部網路可能會意外將 DNS 要求轉送至外部名稱伺服器。攻擊者可為所掌控的名稱伺服器註冊網域，藉此利用受到入侵的容器在 DNS 查詢中將資料進行編碼，最終透過名稱伺服器取得解碼的資料。

    Docker Desktop 一律會在 RFC 1918 位址上執行內部解析器，因此不會受到影響。

    Moby 26.0.0、25.0.4 和 23.0.11 版已經過修補，可避免從內部網路轉送 DNS 要求。您可以改為使用自訂上游位址執行預定單獨附加至內部網路的容器，這會強制從容器的網路命名空間解析所有上游 DNS 查詢 (CVE-2024-29018)。

    moby v25.0.0 - v26.0.2 容易受到透過 daemon/images/image_history.go 造成的 NULL 指標解除參照影響。
    (CVE-2024-36620)

    moby v25.0.3 在 streamformatter 套件中有一個爭用情形弱點，可用來觸發多個並行寫入作業，進而導致資料損毀或應用程式損毀。
    (CVE-2024-36623)

    AWS 已註意到 CVE-2024-41110，這是 Amazon Linux 的 docker 套件中會影響 Moby 開放原始碼專案的問題。Docker 是包含數個開放原始碼容器管理系統的元件。

    此問題不會影響 docker 伺服器的預設設定。如果啟用了授權外掛程式，則針對 docker 程序特製的 API 要求將被轉送至授權外掛程式，其轉送方式可能導致特權提升等非預期動作。啟用授權外掛程式是非典型設定。在預設、典型或建議的設定中，受影響的 API 端點不會洩漏給網路。預設的 EKS 和 ECS 設定不會將 API 端點洩漏給網路。使用 ECS 時，不支援啟用 docker 授權外掛程式。最後，docker 未安裝在比 1.24 新的 EKS AMI 上。雖然 docker 已安裝在 EKS 1.24 和更舊版本中，但 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
206635	Amazon Linux 2 : docker (ALASECS-2024-042)	Nessus	Amazon Linux Local Security Checks	2024/9/5	2025/3/13	critical
204943	Amazon Linux 2 : docker (ALASDOCKER-2024-040)	Nessus	Amazon Linux Local Security Checks	2024/8/1	2025/4/10	high
204929	Amazon Linux 2 : docker (ALASNITRO-ENCLAVES-2024-041)	Nessus	Amazon Linux Local Security Checks	2024/7/31	2025/4/10	high
204943	Amazon Linux 2: docker (ALASDOCKER-2024-040)	Nessus	Amazon Linux Local Security Checks	2024/8/1	2025/4/10	high
204929	Amazon Linux 2: docker (ALASNITRO-ENCLAVES-2024-041)	Nessus	Amazon Linux Local Security Checks	2024/7/31	2025/4/10	high
204929	Amazon Linux 2：docker (ALASNITRO-ENCLAVES-2024-041)	Nessus	Amazon Linux Local Security Checks	2024/7/31	2025/4/10	high
204943	Amazon Linux 2：docker (ALASDOCKER-2024-040)	Nessus	Amazon Linux Local Security Checks	2024/8/1	2025/4/10	high
206635	Amazon Linux 2: docker (ALASECS-2024-042)	Nessus	Amazon Linux Local Security Checks	2024/9/5	2025/3/13	critical
206635	Amazon Linux 2：docker (ALASECS-2024-042)	Nessus	Amazon Linux Local Security Checks	2024/9/5	2025/3/13	critical
204943	Amazon Linux 2：docker (ALASDOCKER-2024-040)	Nessus	Amazon Linux Local Security Checks	2024/8/1	2025/4/10	high
204929	Amazon Linux 2：docker (ALASNITRO-ENCLAVES-2024-041)	Nessus	Amazon Linux Local Security Checks	2024/7/31	2025/4/10	high
206635	Amazon Linux 2：docker (ALASECS-2024-042)	Nessus	Amazon Linux Local Security Checks	2024/9/5	2025/3/13	critical

检测

插件搜索

critical

high

high

high

high

high

high

critical

critical

high

high

critical