Bug 1227888 (CVE-2024-6197) - VUL-0: CVE-2024-6197: curl: freeing stack buffer in utf8asn1str
Summary: VUL-0: CVE-2024-6197: curl: freeing stack buffer in utf8asn1str
Status: RESOLVED INVALID
Alias: CVE-2024-6197
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Pedro Monreal Gonzalez
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/414171/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-16 08:12 UTC by Carlos López
Modified: 2024-07-24 08:42 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos López 2024-07-16 08:12:29 UTC
Via distros:

Hello distros,

I want to pre-alert you of this coming curl security advisory that we will 
announce in association with the pending release of curl 8.9.0, on July 24.

Because the severity level is set to "medium", the fix has already been 
commited in the git repository (but without mentioing the security impact).

freeing stack buffer in utf8asn1str
===================================

Project curl Security Advisory, July 24th 2024 -
[Permalink](https://curl.se/docs/CVE-2024-6197.html)

VULNERABILITY
-------------

libcurl's ASN1 parser has this utf8asn1str() function used for parsing an
ASN.1 UTF-8 string. It can detect an invalid field and return error.
Unfortunately, when doing so it also invokes `free()` on a 4 byte local stack
buffer.

Most modern malloc implementations detect this error and immediately abort.
Some however accept the input pointer and add that memory to its list of
available chunks. This leads to the overwriting of nearby stack memory. The
content of the overwrite is decided by the `free()` implementation; likely to
be memory pointers and a set of flags.

The most likely outcome of exploting this flaw is a crash, although it cannot
be ruled out that more serious results can be had in special circumstances.

INFO
----

The vulnerable code path can be triggered by a malicious server offering an
especially crafted TLS certificate.

This bug was introduced in a code refactor shipped in the curl 8.6.0 release
and 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-6197 to this issue.

CWE-590: Free of Memory not on the Heap

Severity: Medium

AFFECTED VERSIONS
-----------------

The vulnerable code can only be reached when curl is built to use GnuTLS,
wolfSSL, Schannel or Secure Transport. Builds using other TLS backends are not
vulnerable.

- Affected versions: curl 8.6.0 to and including 8.8.0
- Not affected versions: curl < 8.6.0 and >= 8.8.0
- Introduced-in: https://github.com/curl/curl/commit/623c3a8fa0bdb2751f1

libcurl is used by many applications, but not always advertised as such!

SOLUTION
------------

- Fixed-in: https://github.com/curl/curl/commit/3a537a4db9e65e545

RECOMMENDATIONS
---------------

We suggest you take one of the following actions immediately, in order of
preference:

  A - Upgrade curl and libcurl to version 8.9.0

  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 June 19, 2024. We contacted
distros@openwall on July 15, 2024.

curl 8.9.0 was released on July 24 2024 around 06:00 UTC, coordinated with
the publication of this advisory.

CREDITS
-------

- Reported-by: z2_
- Patched-by: z2_

Thanks a lot!
Comment 3 Carlos López 2024-07-16 08:38:17 UTC
(In reply to Carlos López from comment #0)
> AFFECTED VERSIONS
> -----------------
> 
> The vulnerable code can only be reached when curl is built to use GnuTLS,
> wolfSSL, Schannel or Secure Transport. Builds using other TLS backends are
> not
> vulnerable.
> 
> - Affected versions: curl 8.6.0 to and including 8.8.0
> - Not affected versions: curl < 8.6.0 and >= 8.8.0
> - Introduced-in: https://github.com/curl/curl/commit/623c3a8fa0bdb2751f1

We have:
 - SUSE:SLE-12:Update/curl 7.37.0
 - SUSE:SLE-12-SP4:Update/curl 7.60.0
 - SUSE:SLE-12-SP5:Update/curl 8.0.1
 - SUSE:SLE-15:Update/curl 7.60.0
 - SUSE:SLE-15-SP2:Update/curl 7.66.0
 - SUSE:SLE-15-SP4:Update/curl 8.0.1
 - SUSE:SLE-15-SP6:Update/curl 8.6.0 (Affected)
 - SUSE:ALP:Source:Standard:1.0/curl 8.6.0 (Affected)
 - SUSE:SLFO:Main/curl 8.6.0 (Affected)
 - openSUSE:Factory/curl 8.8.0

Although I don't think we use GnuTLS, wolfSSL, Schannel or Secure Transport as backend.
Comment 4 Pedro Monreal Gonzalez 2024-07-16 08:54:54 UTC
(In reply to Carlos López from comment #3)
> (In reply to Carlos López from comment #0)
> > AFFECTED VERSIONS
> > -----------------
> > 
> > The vulnerable code can only be reached when curl is built to use GnuTLS,
> > wolfSSL, Schannel or Secure Transport. Builds using other TLS backends are
> > not
> > vulnerable.
> > 
> > - Affected versions: curl 8.6.0 to and including 8.8.0
> > - Not affected versions: curl < 8.6.0 and >= 8.8.0
> > - Introduced-in: https://github.com/curl/curl/commit/623c3a8fa0bdb2751f1
> 
> We have:
>  - SUSE:SLE-12:Update/curl 7.37.0
>  - SUSE:SLE-12-SP4:Update/curl 7.60.0
>  - SUSE:SLE-12-SP5:Update/curl 8.0.1
>  - SUSE:SLE-15:Update/curl 7.60.0
>  - SUSE:SLE-15-SP2:Update/curl 7.66.0
>  - SUSE:SLE-15-SP4:Update/curl 8.0.1
>  - SUSE:SLE-15-SP6:Update/curl 8.6.0 (Affected)
>  - SUSE:ALP:Source:Standard:1.0/curl 8.6.0 (Affected)
>  - SUSE:SLFO:Main/curl 8.6.0 (Affected)
>  - openSUSE:Factory/curl 8.8.0
> 
> Although I don't think we use GnuTLS, wolfSSL, Schannel or Secure Transport
> as backend.

Right, we don't build with any of that dependencies and configure options.
Comment 5 Carlos López 2024-07-16 09:26:39 UTC
Nothing to do, closing.
Comment 6 Gianluca Gabrielli 2024-07-24 06:56:02 UTC
Public: https://curl.se/docs/CVE-2024-6197.html

VULNERABILITY

libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. It can detect an invalid field and return error. Unfortunately, when doing so it also invokes free() on a 4 byte local stack buffer.

Most modern malloc implementations detect this error and immediately abort. Some however accept the input pointer and add that memory to its list of available chunks. This leads to the overwriting of nearby stack memory. The content of the overwrite is decided by the free() implementation; likely to be memory pointers and a set of flags.

The most likely outcome of exploting this flaw is a crash, although it cannot be ruled out that more serious results can be had in special circumstances.
INFO

The vulnerable code path can be triggered by a malicious server offering an especially crafted TLS certificate.

This bug was introduced in a code refactor shipped in the curl 8.6.0 release and 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-6197 to this issue.

CWE-590: Free of Memory not on the Heap

Severity: Medium
AFFECTED VERSIONS

The vulnerable code can only be reached when curl is built to use GnuTLS, wolfSSL, Schannel or Secure Transport. Builds using other TLS backends are not vulnerable.

    Affected versions: curl 8.6.0 to and including 8.8.0
    Not affected versions: curl < 8.6.0 and >= 8.9.0
    Introduced-in: https://github.com/curl/curl/commit/623c3a8fa0bdb2751f1

libcurl is used by many applications, but not always advertised as such!
SOLUTION

    Fixed-in: https://github.com/curl/curl/commit/3a537a4db9e65e545
Comment 7 Pedro Monreal Gonzalez 2024-07-24 08:42:58 UTC
Factory update to curl 8.9.0:
   * https://build.opensuse.org/request/show/1189336