CVE-2023-32681
ADVISORY - githubSummary
Impact
Since Requests v2.3.0, Requests has been vulnerable to potentially leaking Proxy-Authorization
headers to destination servers, specifically during redirects to an HTTPS origin. This is a product of how rebuild_proxies
is used to recompute and reattach the Proxy-Authorization
header to requests when redirected. Note this behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. https://username:password@proxy:8080
).
Current vulnerable behavior(s):
- HTTP → HTTPS: leak
- HTTPS → HTTP: no leak
- HTTPS → HTTPS: leak
- HTTP → HTTP: no leak
For HTTP connections sent through the proxy, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the Proxy-Authorization
header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.
The reason this currently works for HTTPS connections in Requests is the Proxy-Authorization
header is also handled by urllib3 with our usage of the ProxyManager in adapters.py with proxy_manager_for
. This will compute the required proxy headers in proxy_headers
and pass them to the Proxy Manager, avoiding attaching them directly to the Request object. This will be our preferred option going forward for default usage.
Patches
Starting in Requests v2.31.0, Requests will no longer attach this header to redirects with an HTTPS destination. This should have no negative impacts on the default behavior of the library as the proxy credentials are already properly being handled by urllib3's ProxyManager.
For users with custom adapters, this may be potentially breaking if you were already working around this behavior. The previous functionality of rebuild_proxies
doesn't make sense in any case, so we would encourage any users impacted to migrate any handling of Proxy-Authorization directly into their custom adapter.
Workarounds
For users who are not able to update Requests immediately, there is one potential workaround.
You may disable redirects by setting allow_redirects
to False
on all calls through Requests top-level APIs. Note that if you're currently relying on redirect behaviors, you will need to capture the 3xx response codes and ensure a new request is made to the redirect destination.
import requests
r = requests.get('http://github.com/', allow_redirects=False)
Credits
This vulnerability was discovered and disclosed by the following individuals.
Dennis Brinkrolf, Haxolot (https://haxolot.com/) Tobias Funke, (tobiasfunke93@gmail.com)
Common Weakness Enumeration (CWE)
Exposure of Sensitive Information to an Unauthorized Actor
Exposure of Sensitive Information to an Unauthorized Actor
Transmission of Private Resources into a New Sphere ('Resource Leak')
GitHub
1.6
CVSS SCORE
6.1mediumPackage | Type | OS Name | OS Version | Affected Ranges | Fix Versions |
---|---|---|---|---|---|
requests | pypi | - | - | >=2.3.0,<2.31.0 | 2.31.0 |
CVSS:3 Severity and metrics
The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification.
The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).
A successful attack depends on conditions beyond the attacker's control, requiring investing a measurable amount of effort in research, preparation, or execution against the vulnerable component before a successful attack.
The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator.
An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.
There is a total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
There is no loss of trust or accuracy within the impacted component.
There is no impact to availability within the impacted component.
NIST
1.6
CVSS SCORE
6.1mediumDebian
-
Ubuntu
1.6
CVSS SCORE
6.1mediumAlma
-
CVSS SCORE
N/AmediumAlma
-
CVSS SCORE
N/AmediumAlma
-
CVSS SCORE
N/AmediumAlma
-
CVSS SCORE
N/AmediumAlma
-
CVSS SCORE
N/AmediumAmazon
-
CVSS SCORE
N/AmediumAmazon
-
CVSS SCORE
N/AmediumAmazon
-
CVSS SCORE
N/AmediumRed Hat
1.6
CVSS SCORE
6.1mediumRocky
-
CVSS SCORE
N/AlowRocky
-
CVSS SCORE
N/AhighOracle
-
CVSS SCORE
N/AmediumOracle
-
CVSS SCORE
N/AmediumOracle
-
CVSS SCORE
N/AmediumOracle
-
CVSS SCORE
N/AmediumOracle
-
CVSS SCORE
N/AmediumChainguard
CGA-jw5m-ghm3-2mhw
-
intheWild
-
-