Impact
Clients could clobber values set by intermediate proxies (such as X-Forwarded-For) by providing a underscore version of the same header (X-ForwardedFor). Any users trusting headers set by their proxy may be affected. Attackers may be able to downgrade connections to HTTP (non-SSL) or redirect responses, which could cause confidentiality leaks if combined with a separate MITM attack.
Patches v6.4.3/v5.6.9 now discards any headers using underscores if the non-underscore version also exists. Effectively, allowing the proxy defined headers to always win.
Workarounds Nginx has a underscoresinheaders configuration variable to discard these headers at the proxy level.
Any users that are implicitly trusting the proxy defined headers for security or availability should immediately cease doing so until upgraded to the fixed versions.
A HTTP request smuggling flaw was found in puma. This issue occurs when using puma behind a proxy. Puma does not validate incoming HTTP requests, as per RFC specification, leading to loss of integrity.
A flaw was found in rubygem-puma. A poorly-behaved client could use keepalive requests to monopolize Puma's reactor and create a denial of service attack. If more keepalive connections to Puma are opened than there are threads available, additional connections will wait permanently if the attacker sends requests frequently enough.
Impact
By using an invalid transfer-encoding header, an attacker could smuggle an HTTP response.
Originally reported by @ZeddYu, who has our thanks for the detailed report.
Patches
The problem has been fixed in Puma 3.12.5 and Puma 4.3.4.
For more information
If you have any questions or comments about this advisory:
Open an issue in Puma See our security policy
Impact This is a similar but different vulnerability to the one patched in 3.12.5 and 4.3.4.
A client could smuggle a request through a proxy, causing the proxy to send a response back to another unknown client.
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.
Patches
The problem has been fixed in Puma 3.12.6 and Puma 4.3.5.
For more information
If you have any questions or comments about this advisory:
Open an issue in Puma See our security policy