[<prev] [next>] [day] [month] [year] [list]
Message-ID: <p721n399-8rq8-rs03-1084-3np038sr9032@unkk.fr>
Date: Wed, 31 Jul 2024 09:19:47 +0200 (CEST)
From: Daniel Stenberg <daniel@...x.se>
To: curl security announcements -- curl users <curl-users@...ts.haxx.se>,
curl-announce@...ts.haxx.se, libcurl hacking <curl-library@...ts.haxx.se>,
oss-security@...ts.openwall.com
Subject: [SECURITY ADVISORY] curl: CVE-2024-7264 ASN.1 date parser overread
ASN.1 date parser overread
==========================
Project curl Security Advisory, July 31st 2024 -
[Permalink](https://curl.se/docs/CVE-2024-7264.html)
VULNERABILITY
-------------
libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an
ASN.1 Generalized Time field. If given an syntactically incorrect field, the
parser might end up using -1 for the length of the *time fraction*, leading to
a `strlen()` getting performed on a pointer to a heap buffer area that is not
(purposely) null terminated.
This flaw most likely leads to a crash, but can also lead to heap contents
getting returned to the application when
[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.
INFO
----
The ANS.1 parsing is done *after* a successful TLS handshake, which then also
means that the used TLS library has parsed the certificate. If the TLS library
rejects the bad date string, then it cannot reach and trigger libcurl's bug.
We can however not be sure that there are not circumstances in which the bad
data still gets parsed by libcurl.
This bug is considered a *C mistake* (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-2024-7264 to this issue.
CWE-125: Out-of-bounds Read
Severity: Low
AFFECTED VERSIONS
-----------------
The vulnerable code can only be reached when curl is built to use GnuTLS,
Schannel, Secure Transport or mbedTLS. Builds using other TLS backends are not
vulnerable.
- Affected versions: curl 7.32.0 to and including 8.9.0
- Not affected versions: curl < 7.32.0 and >= 8.9.1
- Introduced-in: https://github.com/curl/curl/commit/3a24cb7bc45
libcurl is used by many applications, but not always advertised as such!
This parser bug was actually introduced in curl 7.32.0 but was then used only
by the GSKit TLS backend which is no longer supported. The functionality was
later brought to other TLS backends in different versions, so this bug affects
curl built with different backends starting in different versions:
- GnuTLS since 7.42.0
- Schannel since 7.50.0
- Secure Transport since 7.79.0
- mbedTLS since 8.9.0
SOLUTION
------------
- Fixed-in: https://github.com/curl/curl/commit/27959ecce75cdb2
Note that this fixing commit was a follow-up to this previous incomplete fix:
https://github.com/curl/curl/commit/3c914bc680155b321
RECOMMENDATIONS
---------------
We suggest you take one of the following actions immediately, in order of
preference:
A - Upgrade curl and libcurl to version 8.9.1
B - Apply the patch to your version and rebuild
C - Build your libcurl with an unaffected TLS backend
TIMELINE
---------
This issue was reported to the curl project on July 30, 2024. We contacted
distros@...nwall on July 30, 2024.
curl 8.9.1 was released on July 31 2024 around 06:00 UTC, coordinated with
the publication of this advisory.
CREDITS
-------
- Reported-by: Dov Murik (Transmit Security)
- Patched-by: Daniel Stenberg
- Patched-by: Stefan Eissing
Thanks a lot!
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
