Due to improper input validation Squid is vulnerable to an HTTP Request Smuggling attack. This problem allows a trusted client to perform HTTP Request Smuggling and access services otherwise forbidden by Squid security controls.
Created squid tracking bugs for this issue: Affects: fedora-all [bug 1939927]
External References: https://github.com/squid-cache/squid/security/advisories/GHSA-jvf6-h9gj-pmj6
Upstream fix: https://github.com/squid-cache/squid/commit/dfd818595b54942cb1adc45f6aed95c9b706e3a8
Mitigation: This flaw can be mitigated by setting the `uri_whitespace` directive in squid.conf to either: ``` uri_whitespace deny ``` or ``` uri_whitespace encode ```
The 'uri_whitespace' directive is responsible for handling requests that have whitespace characters in the URI: http://www.squid-cache.org/Doc/config/uri_whitespace/. From the above advisory, the only options that are *not* vulnerable are 'deny' and 'encode'. Note that the default value (strip) is affected, and the absence of uri_whitespace is affected too.
Although not explicitly stated in the GitHub security advisory, squid v3.5 is not supported upstream [1] and hence not tested for this vulnerability. However, the same vulnerable code can be found in src/url.cc in the way the urlParse() method parses an HTTP request URL [2]. Note that Red Hat Enterprise Linux 7 is potentially affected by this flaw as it ships Squid version 3.5.20 with the same vulnerable pattern in src/url.cc. [1] http://www.squid-cache.org/Versions [2] https://github.com/squid-cache/squid/blob/v3.5/src/url.cc#L295
In an HTTP request smuggling attack a front-end proxy like Squid receives HTTP requests from one or more users and forwards them to a back-end server. For performance reasons, these requests are typically sent over the same network connection. The front-end and back-end systems need to agree about the boundaries between requests, to avoid possible misinterpretation that may lead, for example, part of one request to be interpreted by the back-end server as the start of the next request. In this case specifically, an attacker may be able to break the synchronization by sending a specially crafted HTTP request containing whitespace characters in the request URI within the HTTP request line. This could interfere with the way the Squid proxy and the back-end application will process that request. Also note that this flaw does not appear to be tied to a specific proxy mode (forward vs reverse).
Statement: This flaw is not tied to a specific proxy type (e.g., forward or reverse) and has been rated as having a security impact of Important. This flaw affects the versions of Squid as shipped with Red Hat Enterprise Linux 7 and 8, and is not currently planned to be addressed in future updates of Red Hat Enterprise Linux 6. Red Hat Enterprise Linux 6 is now in Extended Life Phase of the support and maintenance life cycle. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.
Upstream advisory (comment 2) states that this issue allows a trusted client to perform an HTTP Request Smuggling attack. In Squid context, "trusted" refers to a client that can normally be expected to use the proxy, meaning that it adheres to the rules specified in the 'http_access' directive: http://www.squid-cache.org/Doc/config/http_access. This definition does not necessarily imply that clients are to be considered trusted always and by default. From a security perspective, it really comes down to how those rules are set up in a context-specific way. Under some circumstances (e.g., Squid used as a reverse proxy) the proxy may be configured in such a way to accept requests from any clients, thus increasing the impact of this vulnerability.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2021:1135 https://access.redhat.com/errata/RHSA-2021:1135
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-25097
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1979 https://access.redhat.com/errata/RHSA-2021:1979
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Extended Update Support Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2021:2025 https://access.redhat.com/errata/RHSA-2021:2025