Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2025/VULN067 _____________________________________________________________________ DATE : 05/02/2025 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running curl versions prior to 8.12.0. ===================================================================== https://curl.se/docs/CVE-2025-0167.html https://curl.se/docs/CVE-2025-0665.html https://curl.se/docs/CVE-2025-0725.html _____________________________________________________________________ CVE-2025-0167 netrc and default credential leak Project curl Security Advisory, February 5th 2025 - Permalink VULNERABILITY When asked to use a .netrc file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a default entry that omits both login and password. A rare circumstance. INFO A curl transfer with nn.tld that redirects to zz.tld, using a .netrc file with an empty default entry like below, would make curl pass on maryspassword as password even in the transfer to the second and separate host zz.tld. machine nn.tld login mary password maryspassword default This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C. This flaw also affects the curl command line tool. This flaw is similar, but not identical, to CVE-2024-11053. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-0167 to this issue. CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Severity: Low AFFECTED VERSIONS Affected versions: curl 7.76.0 to and including 8.11.1 Not affected versions: curl < 7.76.0 and >= 8.12.0 Introduced-in: https://github.com/curl/curl/commit/46620b97431e19c53ce82e5 libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/0e120c5b925e8ca75d5319e RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.12.0 B - Apply the patch to your version and rebuild C - Avoid using netrc together with redirects TIMELINE This issue was reported to the curl project on December 30, 2024. We contacted distros@openwall on January 28, 2025. curl 8.12.0 was released on February 5 2025 around 08:00 UTC, coordinated with the publication of this advisory. CREDITS Reported-by: Yihang Zhou Patched-by: Daniel Stenberg Thanks a lot! _____________________________________________________________________ CVE-2025-0665 eventfd double close Project curl Security Advisory, February 5th 2025 - Permalink VULNERABILITY libcurl would wrongly close the same eventfd file descriptor twice when taking down a connection channel after having completed a threaded name resolve. INFO This flaw requires libcurl to get built with the threaded resolver It requires that eventfd is used in the curl build. This feature is only used on 64-bit architectures. The eventfd socket is used for inter-thread messaging and since the communication was originally written to use socketpair() only, there was two close() calls done and the superfluous one was left accidentally used because of an #ifdef mistake. This bug was reported (and fixed) immediately after the 8.11.1 release, but the security impact was not considered until later. This bug causes libcurl to act unreliably which many users will have noticed and either avoided eventfd or the vulnerable version, thus somewhat reducing the impact of this problem. It can also be worth noting that both close() calls are typically called within a few dozens of instructions, severely limiting the ability for an external party to control which other file descriptor this can be made to affect. This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C. This flaw also affects the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-0665 to this issue. CWE-1341: Multiple Releases of Same Resource or Handle Severity: Low AFFECTED VERSIONS Affected version: curl 8.11.1 Not affected versions: curl < 8.11.1 and >= 8.12.0 Introduced-in: https://github.com/curl/curl/commit/92124838c6b7e09e3f35f libcurl is used by many applications, but not always advertised as such! SOLUTION Fixed-in: https://github.com/curl/curl/commit/ff5091aa9f73802e894b1cbdf RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.12.0 B - Apply the patch to your version and rebuild C - Disable eventfd use in your build D - Use the c-ares resolver backend TIMELINE This issue was reported to the curl project on January 22, 2025. We contacted distros@openwall on January 28, 2025. curl 8.12.0 was released on February 5 2025 around 08:00 UTC, coordinated with the publication of this advisory. CREDITS Reported-by: Ankom Coper Patched-by: Andy Pan The original bug was first reported as a "normal" bug, by: Reported-by: Christian Heusel Thanks a lot! _____________________________________________________________________ CVE-2025-0725 gzip integer overflow Project curl Security Advisory, February 5th 2025 - Permalink VULNERABILITY When libcurl is asked to perform automatic gzip decompression of content-encoded HTTP responses with the CURLOPT_ACCEPT_ENCODING option, using zlib 1.2.0.3 or older, an attacker-controlled integer overflow would make libcurl perform a buffer overflow. INFO This problem can only trigger when using a run-time zlib version 1.2.0.3 or older. zlib 1.2.0.4 was relased on August 10, 2003. This means zlib versions that do not trigger this problem have been available and used for more than twenty-one years already. A zlib version 1.2.0.3 or earlier still in use is vulnerable to a wide range of security problems and a user using this is already in a spectacularly bad position. libcurl featured code that at run-time takes a different code path for zlib versions before 1.0.2.4 because of lack of functionality in those old versions, and this rarely used piece of code contained the vulnerable code path. This bug is considered a C mistake. It is likely to have been avoided had we not been using C. This flaw also affects the curl command line tool. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2025-0725 to this issue. CWE-680: Integer Overflow to Buffer Overflow Severity: Low While the impact of this problem is potentially huge, we struggled with setting a severity combined with the knowledge that a user vulnerable to this is using an over twenty years old and vulnerable zlib and has practially "given up" all security. If there actually exist users vulnerable to this flaw in the world, they most likely already have worse problems than this to deal with. AFFECTED VERSIONS Affected versions: curl 7.10.5 to and including 8.11.1 Not affected versions: curl < 7.10.5 and >= 8.12.0 Introduced-in: https://github.com/curl/curl/commit/019c4088cfcca0d2b7c5cc4f libcurl is used by many applications, but not always advertised as such! SOLUTION Starting in version 8.12.0, libcurl no longer supports zlib < 1.2.0.4. Using such a version will now instead cause a run-time error. Fixed-in: https://github.com/curl/curl/commit/76f83f0db23846e254d940ec7 RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl and libcurl to version 8.12.0 B - Apply the patch to your version and rebuild C - Use a modern zlib D - Avoid using the CURLOPT_ACCEPT_ENCODING option TIMELINE This issue was reported to the curl project on January 23, 2025. We contacted distros@openwall on January 28, 2025. curl 8.12.0 was released on February 5 2025 around 08:00 UTC, coordinated with the publication of this advisory. CREDITS Reported-by: z2_ Patched-by: Daniel Stenberg Thanks a lot! ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================