Описание
Hackerone: CVE-2023-38545 SOCKS5 heap buffer overflow
FAQ
1. When will an update be available to address this vulnerability?
UPDATE: Microsoft has included version 8.4.0 of curl.exe in Windows updates released on November 14, 2023 for currently supported, on-premise versions of Windows clients and servers. See the Security Updates table in this CVE for the applicable Windows update KB numbers. Windows security updates are cumulative, so future updates will include curl 8.4.0 or higher.
Microsoft is fully aware of this issue and is actively working to release version 8.4.0 of curl.exe in a future Windows update for currently supported, on-premise versions of Windows clients and servers. The Security Updates table for this CVE will be updated with the Windows update KB numbers for all supported versions as they are released. Customers will be notified via a revision to this security vulnerability when those KB numbers are available. If you wish to be notified when these updates are released, we recommend that you register for the security notifications mailer to be alerted of content changes to this CVE. See Microsoft Technical Security Notifications and Security Update Guide Notification System News: Create your profile now – Microsoft Security Response Center.
2. What is the curl open-source project?
Curl is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various network protocols. The name stands for "Client for URL". The Windows implementation provides access to the command-line tool, not the library.
3. Why is this Hackerone CVE included in the Security Update Guide?
The vulnerability assigned to this CVE is in curl.exe software which is consumed by Microsoft Windows. It is being documented in the Security Update Guide to make customers aware that Microsoft Windows is affected by this CVE, and that Microsoft will be including the curl fix for this vulnerability in a future Windows security update. Note that we do not provide CVSS scores for non-Microsoft CVEs. See NVD for scoring information on this CVE.
4. How could an attacker exploit the vulnerability?
This vulnerability is not active by default. To exploit it, the victim must:
- Manually execute the curl.exe utility.
- Be using a SOCKS5 proxy.
- Have a rate limit option (--limit-rate) set to 65540 or lower in the case of the curl.exe utility.
- Use curl to request an attacker-controlled domain OR the attacker must be a machine-in-the-middle (MITM).
For more information see CVE-2023-38545 SOCKS5 heap buffer overflow.
5. What version of curl addresses this CVE?
Curl version 8.4.0 addresses this vulnerability.
6. Where can I find more information about this curl vulnerability?
More information can be found at NVD and curl.se.
7. Are there any workarounds that can be implemented?
IMPORTANT: Under no circumstances should you remove or replace curl.exe
, the curl tool executable, as doing so may damage the Windows Update component store and prevent the installation of further security updates. Instead, we recommend deploying a code integrity policy that restricts the execution of vulnerable versions of curl.exe
.
Note that after you have implemented any of the workarounds the file will still exist on disk, and can still be detected by scanning software. The workaround only provides an operating system level guarantee that the vulnerable version of the curl tool cannot be executed.
Workaround Use a WDAC policy to deny execution of the \system32\curl.exe executable. You can merge the deny into an existing policy or create a new policy with it using the Merge-CIPolicy cmdlet; Merge-CIPolicy (ConfigCI) | Microsoft Learn. After the policy XML file with the deny has been created or merged with an existing policy it must be deployed.
Choose how to deploy the policy by using one of the following methods Deploying Windows Defender Application Control (WDAC) policies | Microsoft Learn:
- Deploy using a Mobile Device Management (MDM) solution, such as Microsoft Intune
- Deploy using Microsoft Configuration Manager
- Deploy via script
- Deploy via group policy Note that after you have deployed a code integrity policy workaround, the file will still exist on disk, and can still be detected by scanning software. The workaround only provides an operating system level guarantee that the vulnerable version of the curl tool cannot be executed.
For example:
Create a new policy: (These steps will create a new policy named Deny-Curl.xml by merging the deny using the example policy named AllowAll.xml)
Merge into an existing policy
How to undo this workaround?
Guidance for how to remove WDAC policies can be found in the following documentation: Remove Windows Defender Application Control (WDAC) policies.
Обновления
Продукт | Статья | Обновление |
---|---|---|
Windows 10 Version 1809 for 32-bit Systems | ||
Windows 10 Version 1809 for x64-based Systems | ||
Windows 10 Version 1809 for ARM64-based Systems | ||
Windows Server 2019 | ||
Windows Server 2019 (Server Core installation) | ||
Microsoft Office 2019 for 32-bit editions | - | |
Microsoft Office 2019 for 64-bit editions | - | |
Microsoft 365 Apps for Enterprise for 32-bit Systems | - | |
Microsoft 365 Apps for Enterprise for 64-bit Systems | - | |
Windows Server 2022 |
Показывать по
Возможность эксплуатации
Publicly Disclosed
Exploited
Latest Software Release
DOS
EPSS
Связанные уязвимости
This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the host name to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that host name can be is 255 bytes. If the host name is detected to be longer, curl switches to local name resolving and instead passes on the resolved address only. Due to this bug, the local variable that means "let the host resolve the name" could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long host name to the target buffer instead of copying just the resolved address there. The target buffer being a heap based buffer, and the host name coming from the URL that curl has been told to operate with.
This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the host name to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that host name can be is 255 bytes. If the host name is detected to be longer, curl switches to local name resolving and instead passes on the resolved address only. Due to this bug, the local variable that means "let the host resolve the name" could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long host name to the target buffer instead of copying just the resolved address there. The target buffer being a heap based buffer, and the host name coming from the URL that curl has been told to operate with.
This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the host name to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that host name can be is 255 bytes. If the host name is detected to be longer, curl switches to local name resolving and instead passes on the resolved address only. Due to this bug, the local variable that means "let the host resolve the name" could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long host name to the target buffer instead of copying just the resolved address there. The target buffer being a heap based buffer, and the host name coming from the URL that curl has been told to operate with.
This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy ...
This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. When curl is asked to pass along the host name to the SOCKS5 proxy to allow that to resolve the address instead of it getting done by curl itself, the maximum length that host name can be is 255 bytes. If the host name is detected to be longer, curl switches to local name resolving and instead passes on the resolved address only. Due to this bug, the local variable that means "let the host resolve the name" could get the wrong value during a slow SOCKS5 handshake, and contrary to the intention, copy the too long host name to the target buffer instead of copying just the resolved address there. The target buffer being a heap based buffer, and the host name coming from the URL that curl has been told to operate with.
EPSS