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.

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.

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.

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.

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.

ID	Name	Product	Family	Severity
164760	Amazon Linux 2022 : (ALAS2022-2022-051)	Nessus	Amazon Linux Local Security Checks	high
164646	Debian DLA-3083-1 : puma - LTS security update	Nessus	Debian Local Security Checks	high
164109	GLSA-202208-28 : Puma: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	high
160523	SUSE SLES15 Security Update : rubygem-puma (SUSE-SU-2022:1515-1)	Nessus	SuSE Local Security Checks	medium
155377	RHEL 7 : Satellite 6.10 Release (Moderate) (RHSA-2021:4702)	Nessus	Red Hat Local Security Checks	critical

Detections

Analytics

CVE-2021-29509

high

Tenable Plugins

high

high

high

medium

critical