CVE-2021-29509

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.

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.

This vulnerability is related to [CVE-2019-16770](https://github.com/puma/puma/security/advisories/GHSA-7xx3-m584-x994). ### Impact 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. ### Patches This problem has been fixed in `puma` 4.3.8 and 5.3.1. ### Workarounds 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](https://en.wikipedia.org/wiki/Slowloris_(computer_security))). The fix is very small. [A git patch is available here](https://gist.github.com/nateberkopec/4b3ea5676c0d70cbb37c82d54be25837) for those using [unsupported versions](https://github.com/puma/puma/security/policy#supported-versions) of Puma. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Puma](https://github.com/puma/puma). * To report problems with this fix or to report another vulnerability, see [our security policy.](https://github.com/puma/puma/security/policy) ### Acknowledgements Thank you to @MSP-Greg, @wjordan and @evanphx for their review on this issue. Thank you to @ioquatix for providing a modified fork of `wrk` which made debugging this issue much easier.

This vulnerability is related to [CVE-2019-16770](https://github.com/puma/puma/security/advisories/GHSA-7xx3-m584-x994). ### Impact 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. ### Patches This problem has been fixed in `puma` 4.3.8 and 5.3.1. ### Workarounds 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](https://en.wikipedia.org/wiki/Slowloris_(computer_security))). The fix is very small. [A git patch is available here](https://gist.github.com/nateberkopec/4b3ea5676c0d70cbb37c82d54be25837) for those using [unsupported versions](https://github.com/puma/puma/security/policy#supported-versions) of Puma. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Puma](https://github.com/puma/puma). * To report problems with this fix or to report another vulnerability, see [our security policy.](https://github.com/puma/puma/security/policy) ### Acknowledgements Thank you to @MSP-Greg, @wjordan and @evanphx for their review on this issue. Thank you to @ioquatix for providing a modified fork of `wrk` which made debugging this issue much easier.

Puma es un servidor HTTP versión 1.1 concurrente para aplicaciones Ruby/Rack. La solución para CVE-2019-16770 estaba incompleta. La corrección original solo protegía las conexiones existentes que ya habían sido aceptadas para evitar que sus peticiones se vieran muertas por conexiones persistentes codiciosas que saturaban todos los hilos en el mismo proceso. Sin embargo, es posible que las conexiones persistentes codiciosas sigan privando a las nuevas conexiones que saturan todos los subprocesos en todos los procesos del clúster. Un servidor "puma" que recibiera más conexiones "keep-alive" simultáneas de las que el servidor tenía subprocesos en su grupo de subprocesos daría servicio sólo a un subconjunto de conexiones, negando el servicio a las conexiones no atendidas. Este problema se ha solucionado en "puma" versiones 4.3.8 y 5.3.1. La configuración de "queue_requests false" también soluciona el problema. Esto no se recomienda cuando se usa "puma" sin un proxy inverso, como "nginx" o "apache", porque te expondrás a ataques lentos de clientes (por ejemplo, slowloris). La solución es muy pequeña y hay un parche de git disponible para aquellos que usan versiones no compatibles de Puma