The remote host is affected by the vulnerability described in GLSA-202208-28 (Puma: Multiple Vulnerabilities)

  - Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was     incomplete. The original fix only protected existing connections that had already been accepted from     having their requests starved by greedy persistent-connections saturating all threads in the same process.
    However, new connections may still be starved by greedy persistent-connections saturating all threads in     all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than     the server had threads in its threadpool would service only a subset of connections, denying service to     the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests     false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as     `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is     very small and a git patch is available for those using unsupported versions of Puma. (CVE-2021-29509)

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - Puma is a simple, fast, multi-threaded, parallel HTTP 1.1 server for Ruby/Rack applications. When using     Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230     standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow     requests to be smuggled via the front-end proxy to Puma. The vulnerability has been fixed in 5.6.4 and     4.3.12. Users are advised to upgrade as soon as possible. Workaround: when deploying a proxy in front of     Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard.
    (CVE-2022-24790)

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2022-2022-051 advisory.

  - Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was     incomplete. The original fix only protected existing connections that had already been accepted from     having their requests starved by greedy persistent-connections saturating all threads in the same process.
    However, new connections may still be starved by greedy persistent-connections saturating all threads in     all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than     the server had threads in its threadpool would service only a subset of connections, denying service to     the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests     false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as     `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is     very small and a git patch is available for those using unsupported versions of Puma. (CVE-2021-29509)

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - Puma is a simple, fast, multi-threaded, parallel HTTP 1.1 server for Ruby/Rack applications. When using     Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230     standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow     requests to be smuggled via the front-end proxy to Puma. The vulnerability has been fixed in 5.6.4 and     4.3.12. Users are advised to upgrade as soon as possible. Workaround: when deploying a proxy in front of     Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard.
    (CVE-2022-24790)

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

The remote Debian 10 host has a package installed that is affected by multiple vulnerabilities as referenced in the dla-3083 advisory.

  - Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was     incomplete. The original fix only protected existing connections that had already been accepted from     having their requests starved by greedy persistent-connections saturating all threads in the same process.
    However, new connections may still be starved by greedy persistent-connections saturating all threads in     all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than     the server had threads in its threadpool would service only a subset of connections, denying service to     the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests     false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as     `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is     very small and a git patch is available for those using unsupported versions of Puma. (CVE-2021-29509)

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

  - Puma is a simple, fast, multi-threaded, parallel HTTP 1.1 server for Ruby/Rack applications. When using     Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230     standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow     requests to be smuggled via the front-end proxy to Puma. The vulnerability has been fixed in 5.6.4 and     4.3.12. Users are advised to upgrade as soon as possible. Workaround: when deploying a proxy in front of     Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard.
    (CVE-2022-24790)

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

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

  - Puma は、Ruby/Rack アプリケーション用の同時 HTTP 1.1 サーバーです。CVE-2019-16770 の修正は不完全でした。元の修正は、すでに受け入れられている既存の接続のみを保護し、貪欲な永続的接続が同じプロセスのすべてのスレッドを飽和させてリクエストを枯渇させないようにしていました。
    ただし、新しい接続は、クラスタ内のすべてのプロセスのすべてのスレッドを飽和させる貪欲な持続的接続によって、依然として不足する可能性があります。スレッドプールにスレッドがあるスレッドよりも多くの「keep-alive」接続を同時に受信した「puma」サーバーは、接続のサブセットのみを処理し、サービスされていない接続へのサービスを拒否します。この問題は「puma」4.3.8 および 5.3.1 で修正されています。「queue_requests false」を設定すると、この問題も修正されます。「nginx」や「apache」などのリバースプロキシなしで「puma」を使用する場合、これはお勧めできません。スロークライアント攻撃 (例: slowloris) にさらされるからです。修正は非常に小規模です。サポートされていないバージョンの Puma を使用している場合は、git パッチを使用できます。(CVE-2021-29509)

  - Puma は、Ruby/Rack アプリケーション用の HTTP 1.1 サーバーです。バージョン 5.5.1 および 4.3.9より前では、LF 文字を含む HTTP ヘッダー値を転送するプロキシで「puma」を使用すると、HTTP リクエストのスマグリングが発生する可能性があります。クライアントがプロキシを介してリクエストをスマグリングし、プロキシが応答を別の不明なクライアントに返信する可能性があります。Puma チームが認識している限り、この動作をする唯一のプロキシは Apache Traffic Server です。プロキシが永続的な接続を使用し、クライアントが HTTP パイプラインを通じて別のリクエストを追加する場合、プロキシが誤ってそれを最初のリクエストの本文とみなす可能性があります。ただし、Puma はこれを 2 つのリクエストと見なし、2 つ目のリクエストを処理するとき、プロキシが予期しない応答を返します。プロキシが Puma への永続的な接続を再利用して別のクライアントに別のリクエストを送信した場合、最初のクライアントの 2 番目の応答が 2 番目のクライアントに送信されます。この脆弱性は、Puma 5.5.1 および 4.3.9 でパッチが適用されました。回避策として、「puma」で Apache Traffic Server を使用しないでください。(CVE-2021-41136)

  - Puma は、並列処理のために構築された Ruby/Rack Web サーバーです。「puma」バージョン「5.6.2」より前では、「puma」が応答本文で「close」を呼び出さないときがあります。バージョン「7.0.2.2」より前の Rails では、「CurrentAttributes」実装の正しい機能は閉じられている応答本文に依存していました。これら 2 つの動作の組み合わせ (Puma が本文を閉じない + Rails の Executor 実装) により、情報漏洩が発生します。この問題は Puma バージョン 5.6.2 および 4.3.11 で修正されています。この問題は Rails バージョン 7.02.2、6.1.4.6、6.0.4.6、および 5.2.6.2 で修正されています。パッチを適用した Rails _or_ Puma バージョンにアップグレードすると、この脆弱性が修正されます。(CVE-2022-23634)

  - Puma は、Ruby / Rack アプリケーション用のシンプルかつ高速なマルチスレッドパラレル HTTP 1.1 サーバーです。受信 HTTP リクエストが RFC7230 標準に一致することを適切に検証しないプロキシの背後で Puma を使用する場合、Puma とフロントエンドプロキシが、リクエストの開始点と終了点で一致しない可能性があります。これにより、リクエストがフロントエンドプロキシを介して Pum にスマグリングされる可能性があります。この脆弱性は 5.6.4 と 4.3.12 で修正されました。ユーザーは、至急アップグレードすることが勧められています。回避策 :  Puma の前にプロキシを展開する場合、すべての機能をオンにして、リクエストが RFC7230 標準に一致することを確認します。
    (CVE-2022-24790)

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

したがって、ALAS2022-2022-051 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - Puma は、Ruby/Rack アプリケーション用の同時 HTTP 1.1 サーバーです。CVE-2019-16770 の修正は不完全でした。元の修正は、すでに受け入れられている既存の接続のみを保護し、貪欲な永続的接続が同じプロセスのすべてのスレッドを飽和させてリクエストを枯渇させないようにしていました。
    ただし、新しい接続は、クラスター内のすべてのプロセスのすべてのスレッドを飽和させる貪欲な持続的接続によって、依然として不足する可能性があります。スレッドプールにスレッドがあるスレッドよりも多くの「keep-alive」接続を同時に受信した「puma」サーバーは、接続のサブセットのみを処理し、サービスされていない接続へのサービスを拒否します。この問題は「puma」4.3.8 および 5.3.1 で修正されています。「queue_requests false」を設定すると、この問題も修正されます。「nginx」や「apache」などのリバースプロキシなしで「puma」を使用する場合、これはお勧めできません。スロークライアント攻撃 (例: slowloris) にさらされるからです。修正は非常に小規模です。サポートされていないバージョンの Puma を使用している場合は、git パッチを使用できます。(CVE-2021-29509)

  - Puma は、Ruby/Rack アプリケーション用の HTTP 1.1 サーバーです。バージョン 5.5.1 および 4.3.9より前では、LF 文字を含む HTTP ヘッダー値を転送するプロキシで「puma」を使用すると、HTTP リクエストのスマグリングが発生する可能性があります。クライアントがプロキシを介してリクエストをスマグリングし、プロキシが応答を別の不明なクライアントに返信する可能性があります。Puma チームが認識している限り、この動作をする唯一のプロキシは Apache Traffic Server です。プロキシが永続的な接続を使用し、クライアントが HTTP パイプラインを通じて別のリクエストを追加する場合、プロキシが誤ってそれを最初のリクエストの本文とみなす可能性があります。ただし、Puma はこれを 2 つのリクエストと見なし、2 つ目のリクエストを処理するとき、プロキシが予期しない応答を返します。プロキシが Puma への永続的な接続を再利用して別のクライアントに別のリクエストを送信した場合、最初のクライアントの 2 番目の応答が 2 番目のクライアントに送信されます。この脆弱性は、Puma 5.5.1 および 4.3.9 でパッチが適用されました。回避策として、「puma」で Apache Traffic Server を使用しないでください。(CVE-2021-41136)

  - Puma は、並列処理のために構築された Ruby/Rack Web サーバーです。「puma」バージョン「5.6.2」より前では、「puma」が応答本文で「close」を呼び出さないときがあります。バージョン「7.0.2.2」より前の Rails では、「CurrentAttributes」実装の正しい機能は閉じられている応答本文に依存していました。これら 2 つの動作の組み合わせ (Puma が本文を閉じない + Rails の Executor 実装) により、情報漏洩が発生します。この問題は Puma バージョン 5.6.2 および 4.3.11 で修正されています。この問題は Rails バージョン 7.02.2、6.1.4.6、6.0.4.6、および 5.2.6.2 で修正されています。パッチを適用した Rails _or_ Puma バージョンにアップグレードすると、この脆弱性が修正されます。(CVE-2022-23634)

  - Puma は、Ruby / Rack アプリケーション用のシンプルかつ高速なマルチスレッドパラレル HTTP 1.1 サーバーです。受信 HTTP リクエストが RFC7230 標準に一致することを適切に検証しないプロキシの背後で Puma を使用する場合、Puma とフロントエンドプロキシが、リクエストの開始点と終了点で一致しない可能性があります。これにより、リクエストがフロントエンドプロキシを介して Pum にスマグリングされる可能性があります。この脆弱性は 5.6.4 と 4.3.12 で修正されました。ユーザーは、至急アップグレードすることが勧められています。回避策 :  Puma の前にプロキシを展開する場合、すべての機能をオンにして、リクエストが RFC7230 標準に一致することを確認します。
    (CVE-2022-24790)

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

The remote Redhat Enterprise Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2021:4702 advisory.

    Red Hat Satellite is a systems management tool for Linux-based     infrastructure. It allows for provisioning, remote management, and     monitoring of multiple Linux deployments with a single centralized tool.

    Security Fix(es):
    * python-ecdsa: Unexpected and undocumented exceptions during signature decoding (CVE-2019-14853)
    * python-ecdsa: DER encoding is not being verified in signatures (CVE-2019-14859)
    * rubygem-activerecord-session_store: hijack sessions by using timing attacks targeting the session id     (CVE-2019-25025)
    * rake: OS Command Injection via egrep in Rake::FileList (CVE-2020-8130)
    * candlepin: guava - local information disclosure via temporary directory created with unsafe permissions     (CVE-2020-8908)
    * PyYAML: incomplete fix for CVE-2020-1747 (CVE-2020-14343)
    * tfm-rubygem-nokogiri: XML external entity injection via Nokogiri::XML::Schema (CVE-2020-26247)
    * tfm-rubygem-foreman_azure_rm: Azure compute resource secret_key leak to authenticated users     (CVE-2021-3413)
    * foreman: possible man-in-the-middle in smart_proxy realm_freeipa (CVE-2021-3494)
    * foreman: BMC controller credential leak via API (CVE-2021-20256)
    * python-aiohttp: Open redirect in aiohttp.web_middlewares.normalize_path_middleware (CVE-2021-21330)
    * rubygem-actionpack: Possible Information Disclosure / Unintended Method Execution in Action Pack     (CVE-2021-22885)
    * tfm-rubygem-actionpack: rails: Possible Denial of Service vulnerability in Action Dispatch     (CVE-2021-22902)
    * tfm-rubygem-actionpack: Possible DoS Vulnerability in Action Controller Token Authentication     (CVE-2021-22904)
    * python-django: potential directory-traversal via uploaded files (CVE-2021-28658)
    * tfm-rubygem-puma: incomplete fix for CVE-2019-16770 allows Denial of Service (DoS) (CVE-2021-29509)
    * python-django: Potential directory-traversal via uploaded files (CVE-2021-31542)
    * tfm-rubygem-addressable: ReDoS in templates (CVE-2021-32740)
    * python-django: Potential directory traversal via ``admindocs`` (CVE-2021-33203)
    * python-urllib3: ReDoS in the parsing of authority part of URL (CVE-2021-33503)
    * python-django: Possible indeterminate SSRF, RFI, and LFI attacks since validators accepted leading zeros     in IPv4 addresses (CVE-2021-33571)

    For more details about the security issue(s), including the impact, a CVSS     score, acknowledgments, and other related information, refer to the CVE     page(s) listed in the References section.

    Additional Changes:

    * Updated Content Management backend with Pulp 3 for increased performance, scale and reliability. MongoDB     is also removed from Satellite
    * Adds support for Azure GovCloud
    * Provides Satellite 6.10 Server support for Satellite 6.9 Capsules
    * Improves support for Satellite Air Gapped and Disconnected environments
    * Adds Ansible Collections content type to support disconnected environments
    * Foreman_webhooks introduced to replace foreman_hooks
    * Introduces UI to manage Personal Access Tokens
    * Adds ability to configure Pulp repository synchronization timeouts
    * Support for Convert2RHEL
    * Provides advanced options when registering a host
    * Supports remediation playbook signatures from console.redhat.com
    * Red Hat Insights Plugin replaced through new integration within Satellite
    * Ability to visually represent systems registered and in sync with Insights
    * Ability to verify if required packages are installed as part of pre-upgrade check
    * Ability to unset environment variables when installer is running
    * Ability to turn backups on and off when cleaning up tasks from database

    The items above are not a complete list of changes. This update also fixes     several bugs and adds various enhancements. Documentation for these changes     is available from the Release Notes document linked to in the References     section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux 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 remote SUSE Linux SLES15 / SLES_SAP15 host has a package installed that is affected by multiple vulnerabilities as referenced in the SUSE-SU-2022:1515-1 advisory.

  - Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was     incomplete. The original fix only protected existing connections that had already been accepted from     having their requests starved by greedy persistent-connections saturating all threads in the same process.
    However, new connections may still be starved by greedy persistent-connections saturating all threads in     all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than     the server had threads in its threadpool would service only a subset of connections, denying service to     the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests     false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as     `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is     very small and a git patch is available for those using unsupported versions of Puma. (CVE-2021-29509)

  - Puma is a HTTP 1.1 server for Ruby/Rack applications. Prior to versions 5.5.1 and 4.3.9, using `puma` with     a proxy which forwards HTTP header values which contain the LF character could allow HTTP request     smugggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to     another unknown client. The only proxy which has this behavior, as far as the Puma team is aware of, is     Apache Traffic Server. If the proxy uses persistent connections and the client adds another request in via     HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two     requests, and when processing the second request, send back a response that the proxy does not expect. If     the proxy has reused the persistent connection to Puma to send another request for a different client, the     second response from the first client will be sent to the second client. This vulnerability was patched in     Puma 5.5.1 and 4.3.9. As a workaround, do not use Apache Traffic Server with `puma`. (CVE-2021-41136)

  - Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not     always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body     being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of     these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information     leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions     7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the     vulnerability. (CVE-2022-23634)

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

远程 Debian 10 主机上安装的多个程序包受到 dla-3083 公告中提及的多个漏洞影响。

  - Puma 是用于 Ruby/Rack 应用程序的并发 HTTP 1.1 服务器。针对 CVE-2019-16770 的修复不完整。原始修复程序仅保护已被接受的现有连接，防止其请求被持久连接耗尽，导致相同进程中的所有线程饱和。
    但是，新连接仍可能被持久连接耗尽，使群集中所有进程的所有线程饱和。当接收到的并发“keep-alive”连接超过线程池中的线程数时，“puma”服务器将仅服务其中部分连接，拒绝未提供服务的连接。此问题已在 puma 4.3.8 和 5.3.1 中修复。设置“queue_requests false”也可修复此问题。使用“puma”时若不使用反向代理（如“nginx”或“apache”），则不建议这样做，以免受到慢速客户端攻击（例如 slowloris）。此修复程序非常小，对于使用不受支持的 Puma 版本的用户，还提供了 git 补丁。(CVE-2021-29509)

  - Puma 是用于 Ruby/Rack 应用程序的 HTTP 1.1 服务器。在低于 5.5.1 和 4.3.9 的版本中，通过代理（正向代理包含 LF 字符的 HTTP 标头值）使用 `puma` 可能允许执行 HTTP 请求走私。客户端可通过代理走私请求，导致代理将响应发送回另一个未知客户端。据 Puma 团队所知，会发生此行为的唯一代理是 Apache Traffic Server。如果代理使用持续连接，并且客户端通过 HTTP 管道添加了另一个请求，则代理可能会将其误认为是第一个请求的正文。但是，Puma 会将其视为两个请求，并在处理第二个请求时发回代理未预期的响应。如果代理已重新使用与 Puma 的持续连接为其他客户端发送其他请求，则来自第一个客户端的第二个响应将被发送到第二个客户端。Puma 5.5.1 和 4.3.9 版本已修补此漏洞。有一种变通方案是，不将 Apache Traffic Server 与 `puma` 一起使用。(CVE-2021-41136)

  - Puma 是为实现并行性而构建的 Ruby/Rack Web 服务器。在 `puma` 5.6.2 之前版本中，`puma` 可能不会始终在响应正文中调用 `close`。在 Rails `7.0.2.2` 之前版本中，Rails 需要关闭响应正文，才能使其 `CurrentAttributes` 实现正确工作。这两种行为同时出现（Puma 未关闭正文 + Rails 的 Executor 实现）将会导致信息泄漏。此问题已在 Puma 5.6.2 和 4.3.11 版本中修复。此问题已在 Rails 7.02.2、6.1.4.6、6.0.4.6 和 5.2.6.2 版本中修复。升级到修补后的 Rails _or_ Puma 版本可修复此漏洞。(CVE-2022-23634)

  - Puma 是用于 Ruby/Rack 应用程序的 HTTP 1.1 服务器，简单、快速，可多线程并行执行。在未正确验证传入 HTTP 请求是否符合 RFC7230 标准的代理后面使用 Puma 时，Puma 和前端代理可能会就请求开始和结束的位置上产生分歧。这将允许通过前端代理将请求走私给 Puma。此漏洞已在 5.6.4 和 4.3.12 版本中得到修复。建议用户尽快升级。变通方案如下：在 Puma 前面部署代理时，开启所有功能以确保请求符合 RFC7230 标准。
    (CVE-2022-24790)

请注意，Nessus 尚未测试这些问题，而是只依靠应用程序自我报告的版本号来判断。

遠端 Debian 10 主機上安裝的一個套件受到 dla-3083 公告中提及的多個弱點影響。

  - Puma 是 Ruby/Rack 應用程式的並行 HTTP 1.1 伺服器。CVE-2019-16770 的修正不完整。原始修正程式僅保護已接受的現有連線，防止其要求被持續連線耗盡，導致相同處理程序中的所有執行緒飽和。
    但是，新連線仍可能被持續連線耗盡，使叢集中所有處理程序的所有執行緒飽和。當收到的並行「keep-alive」連線超過執行緒集區中的執行緒數量時，「puma」伺服器只會服務其中部分連線，拒絕未提供服務的連線。此問題已在 puma 4.3.8 和 5.3.1 中修正。設定「queue_requests false」也可修正此問題。在沒有反向代理伺服器的情況下使用「puma」時（如「nginx」或「apache」），不建議這樣做，以免遭到慢速用戶端攻擊 (例如 slowloris)。此修復程式非常小，另有一個 git 修補程式可供使用不受支援的 Puma 版本者使用。(CVE-2021-29509)

  - Puma 是 Ruby/Rack 應用程式的 HTTP 1.1 伺服器。在 5.5.1 和 4.3.9 之前版本中，將 `puma` 與轉送包含 LF 字元之 HTTP 標頭值的代理伺服器一起使用時，將可能允許執行 HTTP 要求走私。用戶端可透過代理伺服器走私要求，造成該伺服器將回應傳送回另一個未知用戶端。據 Puma 團隊所知，唯一具有此行為的代理伺服器是 Apache Traffic Server。如果 Proxy 使用持續連線，而用戶端透過 HTTP 管線化新增其他要求，Proxy 可能會將其誤認為第一個要求的內文。不過，Puma 會將其視為兩個要求，而且在處理第二個要求時，會傳回 Proxy 未預期的回應。如果 Proxy 重複使用與 Puma 的持續連線來傳送其他用戶端的其他要求，則來自第一個用戶端的第二個回應會傳送至第二個用戶端。此弱點已在 Puma 5.5.1 和 4.3.9 版本中得到修補。可以透過不搭配使用 `puma` 與 Apache Traffic Server 來解決此問題。(CVE-2021-41136)

  - Puma 是一個專為實現平行執行而建構的 Ruby/Rack Web 伺服器。在 Puma 5.6.2 之前版本中，`puma` 可能並不總是在回應內文中呼叫 `close`。在 Rails 7.0.2.2 之前版本中，Rails 必須關閉回應內文，其 `CurrentAttributes` 實作才能正確運作。這兩種行為同時出現 (Puma 未關閉內文 + Rails 的 Executor 實作) 會造成資訊洩漏。此問題已在 Puma 5.6.2 和 4.3.11 版本中得到修正。此問題已在 Rails 7.02.2、6.1.4.6、6.0.4.6 和 5.2.6.2 版本中得到修正。升級至修補後的 Rails _or_ Puma 版本可修正該弱點。(CVE-2022-23634)

  - Puma 是用於 Ruby/Rack 應用程式的 HTTP 1.1 伺服器，簡單、快速，且能夠實現多執行緒平行執行。在未正確驗證傳入 HTTP 要求是否符合 RFC7230 標準的代理伺服器後使用 Puma 時，Puma 和前端 Proxy 可能在要求開始和結束的位置上意見不一。這會允許透過前端代理伺服器將要求走私給 Puma。此弱點已在 5.6.4 和 4.3.12 版本中得到修正。建議使用者盡快進行升級。因應措施：在 Puma 前面部署代理伺服器時，開啟所有功能以確保要求符合 RFC7230 標準。
    (CVE-2022-24790)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼。

因此，如公告 ALAS2022-2022-051 所述，受到多个漏洞的影响。

  - Puma 是用于 Ruby/Rack 应用程序的并发 HTTP 1.1 服务器。针对 CVE-2019-16770 的修复不完整。原始修复程序仅保护已被接受的现有连接，防止其请求被持久连接耗尽，导致相同进程中的所有线程饱和。
    但是，新连接仍可能被持久连接耗尽，使群集中所有进程的所有线程饱和。当接收到的并发“keep-alive”连接超过线程池中的线程数时，“puma”服务器将仅服务其中部分连接，拒绝未提供服务的连接。此问题已在 puma 4.3.8 和 5.3.1 中修复。设置“queue_requests false”也可修复此问题。使用“puma”时若不使用反向代理（如“nginx”或“apache”），则不建议这样做，以免受到慢速客户端攻击（例如 slowloris）。此修复程序非常小，对于使用不受支持的 Puma 版本的用户，还提供了 git 补丁。(CVE-2021-29509)

  - Puma 是用于 Ruby/Rack 应用程序的 HTTP 1.1 服务器。在低于 5.5.1 和 4.3.9 的版本中，通过代理（正向代理包含 LF 字符的 HTTP 标头值）使用 `puma` 可能允许执行 HTTP 请求走私。客户端可通过代理走私请求，导致代理将响应发送回另一个未知客户端。据 Puma 团队所知，会发生此行为的唯一代理是 Apache Traffic Server。如果代理使用持续连接，并且客户端通过 HTTP 管道添加了另一个请求，则代理可能会将其误认为是第一个请求的正文。但是，Puma 会将其视为两个请求，并在处理第二个请求时发回代理未预期的响应。如果代理已重新使用与 Puma 的持续连接为其他客户端发送其他请求，则来自第一个客户端的第二个响应将被发送到第二个客户端。Puma 5.5.1 和 4.3.9 版本已修补此漏洞。有一种变通方案是，不将 Apache Traffic Server 与 `puma` 一起使用。(CVE-2021-41136)

  - Puma 是为实现并行性而构建的 Ruby/Rack Web 服务器。在 `puma` 5.6.2 之前版本中，`puma` 可能不会始终在响应正文中调用 `close`。在 Rails `7.0.2.2` 之前版本中，Rails 需要关闭响应正文，才能使其 `CurrentAttributes` 实现正确工作。这两种行为同时出现（Puma 未关闭正文 + Rails 的 Executor 实现）将会导致信息泄漏。此问题已在 Puma 5.6.2 和 4.3.11 版本中修复。此问题已在 Rails 7.02.2、6.1.4.6、6.0.4.6 和 5.2.6.2 版本中修复。升级到修补后的 Rails _or_ Puma 版本可修复此漏洞。(CVE-2022-23634)

  - Puma 是用于 Ruby/Rack 应用程序的 HTTP 1.1 服务器，简单、快速，可多线程并行执行。在未正确验证传入 HTTP 请求是否符合 RFC7230 标准的代理后面使用 Puma 时，Puma 和前端代理可能会就请求开始和结束的位置上产生分歧。这将允许通过前端代理将请求走私给 Puma。此漏洞已在 5.6.4 和 4.3.12 版本中得到修复。建议用户尽快升级。变通方案如下：在 Puma 前面部署代理时，开启所有功能以确保请求符合 RFC7230 标准。
    (CVE-2022-24790)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

因此，會受到 ALAS2022-2022-051 公告中所提及的多個弱點影響。

  - Puma 是 Ruby/Rack 應用程式的並行 HTTP 1.1 伺服器。CVE-2019-16770 的修正不完整。原始修正程式僅保護已接受的現有連線，防止其要求被持續連線耗盡，導致相同處理程序中的所有執行緒飽和。
    但是，新連線仍可能被持續連線耗盡，使叢集中所有處理程序的所有執行緒飽和。當收到的並行「keep-alive」連線超過執行緒集區中的執行緒數量時，「puma」伺服器只會服務其中部分連線，拒絕未提供服務的連線。此問題已在 puma 4.3.8 和 5.3.1 中修正。設定「queue_requests false」也可修正此問題。在沒有反向代理伺服器的情況下使用「puma」時（如「nginx」或「apache」），不建議這樣做，以免遭到慢速用戶端攻擊 (例如 slowloris)。此修復程式非常小，另有一個 git 修補程式可供使用不受支援的 Puma 版本者使用。(CVE-2021-29509)

  - Puma 是 Ruby/Rack 應用程式的 HTTP 1.1 伺服器。在 5.5.1 和 4.3.9 之前版本中，將 `puma` 與轉送包含 LF 字元之 HTTP 標頭值的代理伺服器一起使用時，將可能允許執行 HTTP 要求走私。用戶端可透過代理伺服器走私要求，造成該伺服器將回應傳送回另一個未知用戶端。據 Puma 團隊所知，唯一具有此行為的代理伺服器是 Apache Traffic Server。如果 Proxy 使用持續連線，而用戶端透過 HTTP 管線化新增其他要求，Proxy 可能會將其誤認為第一個要求的內文。不過，Puma 會將其視為兩個要求，而且在處理第二個要求時，會傳回 Proxy 未預期的回應。如果 Proxy 重複使用與 Puma 的持續連線來傳送其他用戶端的其他要求，則來自第一個用戶端的第二個回應會傳送至第二個用戶端。此弱點已在 Puma 5.5.1 和 4.3.9 版本中得到修補。可以透過不搭配使用 `puma` 與 Apache Traffic Server 來解決此問題。(CVE-2021-41136)

  - Puma 是一個專為實現平行執行而建構的 Ruby/Rack Web 伺服器。在 Puma 5.6.2 之前版本中，`puma` 可能並不總是在回應內文中呼叫 `close`。在 Rails 7.0.2.2 之前版本中，Rails 必須關閉回應內文，其 `CurrentAttributes` 實作才能正確運作。這兩種行為同時出現 (Puma 未關閉內文 + Rails 的 Executor 實作) 會造成資訊洩漏。此問題已在 Puma 5.6.2 和 4.3.11 版本中得到修正。此問題已在 Rails 7.02.2、6.1.4.6、6.0.4.6 和 5.2.6.2 版本中得到修正。升級至修補後的 Rails _or_ Puma 版本可修正該弱點。(CVE-2022-23634)

  - Puma 是用於 Ruby/Rack 應用程式的 HTTP 1.1 伺服器，簡單、快速，且能夠實現多執行緒平行執行。在未正確驗證傳入 HTTP 要求是否符合 RFC7230 標準的代理伺服器後使用 Puma 時，Puma 和前端 Proxy 可能在要求開始和結束的位置上意見不一。這會允許透過前端代理伺服器將要求走私給 Puma。此弱點已在 5.6.4 和 4.3.12 版本中得到修正。建議使用者盡快進行升級。因應措施：在 Puma 前面部署代理伺服器時，開啟所有功能以確保要求符合 RFC7230 標準。
    (CVE-2022-24790)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼。

遠端主機受到 GLSA-202208-28 中所述的弱點影響 (Puma：多個弱點)

  - Puma 是 Ruby/Rack 應用程式的並行 HTTP 1.1 伺服器。CVE-2019-16770 的修正不完整。原始修正程式僅保護已接受的現有連線，防止其要求被持續連線耗盡，導致相同處理程序中的所有執行緒飽和。
    但是，新連線仍可能被持續連線耗盡，使叢集中所有處理程序的所有執行緒飽和。當收到的並行「keep-alive」連線超過執行緒集區中的執行緒數量時，「puma」伺服器只會服務其中部分連線，拒絕未提供服務的連線。此問題已在 puma 4.3.8 和 5.3.1 中修正。設定「queue_requests false」也可修正此問題。在沒有反向代理伺服器的情況下使用「puma」時（如「nginx」或「apache」），不建議這樣做，以免遭到慢速用戶端攻擊 (例如 slowloris)。此修復程式非常小，另有一個 git 修補程式可供使用不受支援的 Puma 版本者使用。(CVE-2021-29509)

  - Puma 是 Ruby/Rack 應用程式的 HTTP 1.1 伺服器。在 5.5.1 和 4.3.9 之前版本中，將 `puma` 與轉送包含 LF 字元之 HTTP 標頭值的代理伺服器一起使用時，將可能允許執行 HTTP 要求走私。用戶端可透過代理伺服器走私要求，造成該伺服器將回應傳送回另一個未知用戶端。據 Puma 團隊所知，唯一具有此行為的代理伺服器是 Apache Traffic Server。如果 Proxy 使用持續連線，而用戶端透過 HTTP 管線化新增其他要求，Proxy 可能會將其誤認為第一個要求的內文。不過，Puma 會將其視為兩個要求，而且在處理第二個要求時，會傳回 Proxy 未預期的回應。如果 Proxy 重複使用與 Puma 的持續連線來傳送其他用戶端的其他要求，則來自第一個用戶端的第二個回應會傳送至第二個用戶端。此弱點已在 Puma 5.5.1 和 4.3.9 版本中得到修補。可以透過不搭配使用 `puma` 與 Apache Traffic Server 來解決此問題。(CVE-2021-41136)

  - Puma 是一個專為實現平行執行而建構的 Ruby/Rack Web 伺服器。在 Puma 5.6.2 之前版本中，`puma` 可能並不總是在回應內文中呼叫 `close`。在 Rails 7.0.2.2 之前版本中，Rails 必須關閉回應內文，其 `CurrentAttributes` 實作才能正確運作。這兩種行為同時出現 (Puma 未關閉內文 + Rails 的 Executor 實作) 會造成資訊洩漏。此問題已在 Puma 5.6.2 和 4.3.11 版本中得到修正。此問題已在 Rails 7.02.2、6.1.4.6、6.0.4.6 和 5.2.6.2 版本中得到修正。升級至修補後的 Rails _or_ Puma 版本可修正該弱點。(CVE-2022-23634)

  - Puma 是用於 Ruby/Rack 應用程式的 HTTP 1.1 伺服器，簡單、快速，且能夠實現多執行緒平行執行。在未正確驗證傳入 HTTP 要求是否符合 RFC7230 標準的代理伺服器後使用 Puma 時，Puma 和前端 Proxy 可能在要求開始和結束的位置上意見不一。這會允許透過前端代理伺服器將要求走私給 Puma。此弱點已在 5.6.4 和 4.3.12 版本中得到修正。建議使用者盡快進行升級。因應措施：在 Puma 前面部署代理伺服器時，開啟所有功能以確保要求符合 RFC7230 標準。
    (CVE-2022-24790)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端 Redhat Enterprise Linux 7 主機上安裝的套件受到 RHSA-2021：4702 公告中提及的多個弱點影響。

  - python-ecdsa：簽章解碼期間發生非預期且未記錄的例外狀況 (CVE-2019-14853)

  - python-ecdsa：未在簽章中驗證 DER 編碼 (CVE-2019-14859)

  - rubygem-activerecord-session_store：使用針對工作階段 ID 的定時攻擊來劫持工作階段 (CVE-2019-25025)

  - PyYAML：不完整的 CVE-2020-1747 修正 (CVE-2020-14343)

  - rubygem-nokogiri：透過 Nokogiri: : XML: : Schema 插入 XML 外部實體 (CVE-2020-26247)

  - rake：在 Rake: : FileList 中透過 egrep 的作業系統命令插入 (CVE-2020-8130)

  - guava：透過以不安全的權限建立的暫時目錄，造成本機資訊洩漏 (CVE-2020-8908)

  - Satellite：透過 API 的 BMC 控制器認證洩漏 (CVE-2021-20256)

  - python-aiohttp：在 aiohttp.web_middlewares.normalize_path_middleware 中開啟重新導向 (CVE-2021-21330)

  - rubygem-actionpack：Action Pack 中可能的資訊洩漏/非預期方法執行 (CVE-2021-22885)

  - rails：- Action Dispatch 中可能的拒絕服務弱點 (CVE-2021-22902)

  - rails：Action Controller Token 驗證中可能的 DoS 弱點 (CVE-2021-22904)

  - django：透過上傳檔案的潛在目錄遊走 (CVE-2021-28658)

  - rubygem-puma：CVE-2019-16770 的不完整修復允許拒絕服務 (DoS) (CVE-2021-29509)

  - django：透過上傳檔案的潛在目錄遊走 (CVE-2021-31542)

  - rubygem-addressable：範本中的 ReDoS (CVE-2021-32740)

  - django：透過 ``admindocs`` 的潛在目錄遊走 (CVE-2021-33203)

  - python-urllib3: 剖析 URL 的授權部分時存在 ReDoS 弱點 (CVE-2021-33503)

  - django：由於驗證器接受 IPv4 位址中的前導零，因此可能會發生不確定的 SSRF、RFI 和 LFI 攻擊 (CVE-2021-33571)

  - Satellite：Azure 運算資源 secret_key 洩漏給經驗證的使用者 (CVE-2021-3413)

  - foreman：smart_proxy realm_freeipa 中可能的攔截式攻擊 (CVE-2021-3494)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

远程主机受到 GLSA-202208-28 中所述漏洞的影响（Puma：多个漏洞）

  - Puma 是用于 Ruby/Rack 应用程序的并发 HTTP 1.1 服务器。针对 CVE-2019-16770 的修复不完整。原始修复程序仅保护已被接受的现有连接，防止其请求被持久连接耗尽，导致相同进程中的所有线程饱和。
    但是，新连接仍可能被持久连接耗尽，使群集中所有进程的所有线程饱和。当接收到的并发“keep-alive”连接超过线程池中的线程数时，“puma”服务器将仅服务其中部分连接，拒绝未提供服务的连接。此问题已在 puma 4.3.8 和 5.3.1 中修复。设置“queue_requests false”也可修复此问题。使用“puma”时若不使用反向代理（如“nginx”或“apache”），则不建议这样做，以免受到慢速客户端攻击（例如 slowloris）。此修复程序非常小，对于使用不受支持的 Puma 版本的用户，还提供了 git 补丁。(CVE-2021-29509)

  - Puma 是用于 Ruby/Rack 应用程序的 HTTP 1.1 服务器。在低于 5.5.1 和 4.3.9 的版本中，通过代理（正向代理包含 LF 字符的 HTTP 标头值）使用 `puma` 可能允许执行 HTTP 请求走私。客户端可通过代理走私请求，导致代理将响应发送回另一个未知客户端。据 Puma 团队所知，会发生此行为的唯一代理是 Apache Traffic Server。如果代理使用持续连接，并且客户端通过 HTTP 管道添加了另一个请求，则代理可能会将其误认为是第一个请求的正文。但是，Puma 会将其视为两个请求，并在处理第二个请求时发回代理未预期的响应。如果代理已重新使用与 Puma 的持续连接为其他客户端发送其他请求，则来自第一个客户端的第二个响应将被发送到第二个客户端。Puma 5.5.1 和 4.3.9 版本已修补此漏洞。有一种变通方案是，不将 Apache Traffic Server 与 `puma` 一起使用。(CVE-2021-41136)

  - Puma 是为实现并行性而构建的 Ruby/Rack Web 服务器。在 `puma` 5.6.2 之前版本中，`puma` 可能不会始终在响应正文中调用 `close`。在 Rails `7.0.2.2` 之前版本中，Rails 需要关闭响应正文，才能使其 `CurrentAttributes` 实现正确工作。这两种行为同时出现（Puma 未关闭正文 + Rails 的 Executor 实现）将会导致信息泄漏。此问题已在 Puma 5.6.2 和 4.3.11 版本中修复。此问题已在 Rails 7.02.2、6.1.4.6、6.0.4.6 和 5.2.6.2 版本中修复。升级到修补后的 Rails _or_ Puma 版本可修复此漏洞。(CVE-2022-23634)

  - Puma 是用于 Ruby/Rack 应用程序的 HTTP 1.1 服务器，简单、快速，可多线程并行执行。在未正确验证传入 HTTP 请求是否符合 RFC7230 标准的代理后面使用 Puma 时，Puma 和前端代理可能会就请求开始和结束的位置上产生分歧。这将允许通过前端代理将请求走私给 Puma。此漏洞已在 5.6.4 和 4.3.12 版本中得到修复。建议用户尽快升级。变通方案如下：在 Puma 前面部署代理时，开启所有功能以确保请求符合 RFC7230 标准。
    (CVE-2022-24790)

请注意，Nessus 尚未测试这些问题，而是只依靠应用程序自我报告的版本号来判断。

远程 Redhat Enterprise Linux 7 主机上安装的程序包受到 RHSA-2021: 4702 公告中提及的多个漏洞影响。

  - python-ecdsa：签名解码期间发生非预期且未记录的异常 (CVE-2019-14853)

  - python-ecdsa：未在签名中验证 DER 编码 (CVE-2019-14859)

  - rubygem-activerecord-session_store：使用针对会话 id 的时序攻击劫持会话 (CVE-2019-25025)

  - PyYAML：不完整的 CVE-2020-1747 修复 (CVE-2020-14343)

  - rubygem-nokogiri：通过 Nokogiri: : XML: : Schema 造成 XML 外部实体注入 (CVE-2020-26247)

  - rake：通过 Rake: : FileList 中的 egrep 造成 OS 命令注入 (CVE-2020-8130)

  - guava：通过使用不安全权限创建的临时目录泄露本地信息 (CVE-2020-8908)

  - Satellite：通过 API 造成 BMC 控制器凭据泄露 (CVE-2021-20256)

  - python-aiohttp：aiohttp.web_middlewares.normalize_path_middleware 中存在开放重定向 (CVE-2021-21330)

  - rubygem-actionpack：Action Pack 中可能存在信息泄露/非预期方法执行 (CVE-2021-22885)

  - rails：Action Dispatch 中可能存在拒绝服务漏洞 (CVE-2021-22902)

  - rails：Action Controller Token Authentication 中可能存在 DoS 漏洞 (CVE-2021-22904)

  - django：通过上传的文件可能造成目录遍历 (CVE-2021-28658)

  - rubygem-puma：对 CVE-2019-16770 的修复不完整，可导致拒绝服务 (DoS) (CVE-2021-29509)

  - django：通过上传的文件可能造成目录遍历 (CVE-2021-31542)

  - rubygem-addressable：模板中存在 ReDoS (CVE-2021-32740)

  - django：通过“admindocs”可能造成目录遍历 (CVE-2021-33203)

  - python-urllib3: 解析 URL 授权部分时出现 ReDoS (CVE-2021-33503)

  - django：自验证器接受 IPv4 地址中的前导零后，可能发生不明 SSRF、RFI 和 LFI 攻击 (CVE-2021-33571)

  - Satellite：向经过身份验证的用户泄露 Azure 计算资源 secret_key (CVE-2021-3413)

  - foreman：smart_proxy realm_freeipa 中可能存在中间人漏洞 (CVE-2021-3494)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

リモートのRedhat Enterprise Linux 7ホストにインストールされているパッケージは、RHSA-2021：4702 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - python-ecdsa: 署名デコード中に発生する予期せぬ文書化されていない例外 (CVE-2019-14853)

  - python-ecdsa: DER エンコーディングが署名で検証されていません (CVE-2019-14859)

  - rubygem-activerecord-session_store：セッションIDを標的とするタイミング攻撃を使用してセッションをハイジャック（CVE-2019-25025）

  - PyYAML:CVE-2020-1747の修正が不完全（CVE-2020-14343）

  - rubygem-nokogiri: Nokogiri: : XML：: Schema による XML 外部エンティティインジェクション (CVE-2020-26247)

  - rake: Rake: : FileList の egrep による OS コマンドインジェクション (CVE-2020-8130)

  -guava：安全ではない権限で作成した一時ディレクトリを介したローカルの情報漏洩（CVE-2020-8908）

  - Satellite: API を介した BMC コントローラーの認証情報の漏洩 (CVE-2021-20256)

  - python-aiohttp: aiohttp.web_middlewares.normalize_path_middleware のオープンリダイレクト (CVE-2021-21330)

  - rubygem-actionpack：Action Pack における潜在的な情報漏洩/意図しないメソッドの実行 (CVE-2021-22885)

  - rails: Action Dispatch における潜在的なサービス拒否の脆弱性 (CVE-2021-22902)

  - rails: Action Controller のトークン認証の潜在的な DoS の脆弱性 (CVE-2021-22904)

  - django：アップロードされたファイルを介した潜在的なディレクトリトラバーサル (CVE-2021-28658)

  - rubygem-puma: CVE-2019-16770 の不完全な修正により、サービス拒否 (DoS) が可能になります (CVE-2021-29509)

  - django：アップロードされたファイルを介した潜在的なディレクトリトラバーサル (CVE-2021-31542)

  - rubygem-addressable: テンプレートの ReDoS (CVE-2021-32740)

  - django：「admindocs」を介したディレクトリトラバーサルの可能性 (CVE-2021-33203)

  - python-urllib3: URLの権限部分の解析におけるReDoS（CVE-2021-33503）

  - django：バリデーターが IPv4 アドレスの先行ゼロを受け入れていたために発生する可能性がある不確定な SSRF、RFI、および LFI 攻撃 (CVE-2021-33571)

  - Satellite: 認証されたユーザーへの Azure 計算リソース secret_key の漏洩 (CVE-2021-3413)

  - foreman: smart_proxy realm_freeipa での中間者の可能性 (CVE-2021-3494)

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

リモートの SUSE Linux SLES15 / openSUSE 15 ホストには、SUSE-SU-2022:1515-1 のアドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Puma は、Ruby/Rack アプリケーション用の同時 HTTP 1.1 サーバーです。CVE-2019-16770 の修正は不完全でした。元の修正は、すでに受け入れられている既存の接続のみを保護し、貪欲な永続的接続が同じプロセスのすべてのスレッドを飽和させてリクエストを枯渇させないようにしていました。
    ただし、新しい接続は、クラスター内のすべてのプロセスのすべてのスレッドを飽和させる貪欲な持続的接続によって、依然として不足する可能性があります。スレッドプールにスレッドがあるスレッドよりも多くの「keep-alive」接続を同時に受信した「puma」サーバーは、接続のサブセットのみを処理し、サービスされていない接続へのサービスを拒否します。この問題は「puma」4.3.8 および 5.3.1 で修正されています。「queue_requests false」を設定すると、この問題も修正されます。「nginx」や「apache」などのリバースプロキシなしで「puma」を使用する場合、これはお勧めできません。スロークライアント攻撃 (例: slowloris) にさらされるからです。修正は非常に小規模です。サポートされていないバージョンの Puma を使用している場合は、git パッチを使用できます。(CVE-2021-29509)

  - Puma は、Ruby/Rack アプリケーション用の HTTP 1.1 サーバーです。バージョン 5.5.1 および 4.3.9より前では、LF 文字を含む HTTP ヘッダー値を転送するプロキシで「puma」を使用すると、HTTP リクエストのスマグリングが発生する可能性があります。クライアントがプロキシを介してリクエストをスマグリングし、プロキシが応答を別の不明なクライアントに返信する可能性があります。Puma チームが認識している限り、この動作をする唯一のプロキシは Apache Traffic Server です。プロキシが永続的な接続を使用し、クライアントが HTTP パイプラインを通じて別のリクエストを追加する場合、プロキシが誤ってそれを最初のリクエストの本文とみなす可能性があります。ただし、Puma はこれを 2 つのリクエストと見なし、2 つ目のリクエストを処理するとき、プロキシが予期しない応答を返します。プロキシが Puma への永続的な接続を再利用して別のクライアントに別のリクエストを送信した場合、最初のクライアントの 2 番目の応答が 2 番目のクライアントに送信されます。この脆弱性は、Puma 5.5.1 および 4.3.9 でパッチが適用されました。回避策として、「puma」で Apache Traffic Server を使用しないでください。(CVE-2021-41136)

  - Puma は、並列処理のために構築された Ruby/Rack Web サーバーです。「puma」バージョン「5.6.2」より前では、「puma」が応答本文で「close」を呼び出さないときがあります。バージョン「7.0.2.2」より前の Rails では、「CurrentAttributes」実装の正しい機能は閉じられている応答本文に依存していました。これら 2 つの動作の組み合わせ (Puma が本文を閉じない + Rails の Executor 実装) により、情報漏洩が発生します。この問題は Puma バージョン 5.6.2 および 4.3.11 で修正されています。この問題は Rails バージョン 7.02.2、6.1.4.6、6.0.4.6、および 5.2.6.2 で修正されています。パッチを適用した Rails _or_ Puma バージョンにアップグレードすると、この脆弱性が修正されます。(CVE-2022-23634)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
164109	GLSA-202208-28 : Puma: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	2022/8/15	2022/8/15	high
164760	Amazon Linux 2022 : (ALAS2022-2022-051)	Nessus	Amazon Linux Local Security Checks	2022/9/6	2022/9/6	high
164646	Debian DLA-3083-1 : puma - LTS security update	Nessus	Debian Local Security Checks	2022/9/2	2022/9/2	high
164646	Debian DLA-3083-1: puma - LTS のセキュリティ更新	Nessus	Debian Local Security Checks	2022/9/2	2022/9/2	high
164760	Amazon Linux 2022 : (ALAS2022-2022-051)	Nessus	Amazon Linux Local Security Checks	2022/9/6	2022/9/6	high
155377	RHEL 7 : Satellite 6.10 Release (Moderate) (RHSA-2021:4702)	Nessus	Red Hat Local Security Checks	2021/11/17	2024/6/3	critical
160523	SUSE SLES15 Security Update : rubygem-puma (SUSE-SU-2022:1515-1)	Nessus	SuSE Local Security Checks	2022/5/5	2023/7/14	medium
164646	Debian DLA-3083-1：puma - LTS 安全更新	Nessus	Debian Local Security Checks	2022/9/2	2022/9/2	high
164646	Debian DLA-3083-1：puma - LTS 安全性更新	Nessus	Debian Local Security Checks	2022/9/2	2022/9/2	high
164760	Amazon Linux 2022：(ALAS2022-2022-051)	Nessus	Amazon Linux Local Security Checks	2022/9/6	2022/9/6	high
164760	Amazon Linux 2022: (ALAS2022-2022-051)	Nessus	Amazon Linux Local Security Checks	2022/9/6	2022/9/6	high
164109	GLSA-202208-28：Puma：多個弱點	Nessus	Gentoo Local Security Checks	2022/8/15	2022/8/15	high
155377	RHEL 7：Satellite 6.10 版本 (中等) (RHSA-2021: 4702)	Nessus	Red Hat Local Security Checks	2021/11/17	2024/6/3	critical
164109	GLSA-202208-28：Puma：多个漏洞	Nessus	Gentoo Local Security Checks	2022/8/15	2022/8/15	high
155377	RHEL 7：Satellite 6.10 版本（中等）(RHSA-2021: 4702)	Nessus	Red Hat Local Security Checks	2021/11/17	2024/6/3	critical
155377	RHEL 7：Satellite 6.10 リリース（重要度中）（RHSA-2021：4702)	Nessus	Red Hat Local Security Checks	2021/11/17	2024/6/3	critical
160523	SUSE SLES15 / openSUSE 15 セキュリティ更新: rubygem-puma (SUSE-SU-2022:1515-1)	Nessus	SuSE Local Security Checks	2022/5/5	2023/7/14	medium

偵測

搜尋 Plugin

high

high

high

high

high

critical

medium

high

high

high

high

high

critical

high

critical

critical

medium