Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11

[bagder]

We are cutting the release cycle short and will release curl 8.4.0 on October 11, including fixes for a severity HIGH CVE and one severity LOW. The one rated HIGH is probably the worst curl security flaw in a long time.

The new version and details about the two CVEs will be published around 06:00 UTC on the release day.

• CVE-2023-38545: severity HIGH (affects both libcurl and the curl tool)
• CVE-2023-38546: severity LOW (affects libcurl only, not the tool)

There is no API nor ABI change in the coming curl release.

I cannot disclose any information about which version range that is affected, as that would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The "last several years" of versions is as specific as I can get.

We have notified the distros mailing list allowing the member distributions to prepare patches. (No one else gets details about these problems before October 11 without a support contract and a good reason.)

Now you know. Plan accordingly.

Bonus: How I made a heap overflow in curl

[dreirund]

release curl 8.4.0 on October 11
[...]
probably the worst curl security flaw in a long time.

When there is a HIGH CVE security flaw, why then not release immediately after fix has been applied, but at a set date? (Now, exploit-hunters are aware that there is something and have 7 days notice in which they can focus intensely on curl to find the flaw and exploit it.)

[bagder]

I set the date to

• allow us a few days for more deliberating on the vulnerability, to really think it through, write the advisory, understand it proper. Rinse and repeat.
• give "distro people" a few days to prepare patched updates
• allow a few days for the project (and me) to line up things to prepare for the new release
• we can spread the word about the pending release and the main reason for it in the mean time
• the release needs to work with my personal schedule and Wednesdays are our standard release days

Sure, there is a minuscule risk that someone can find this (again) before we ship the patch, but this issue has stayed undetected for years for a reason. I think taking a few days to make sure we do a solid release is worth this risk.

[realsimix]

I'm wondering about the term "distro people": who is this exactly and how do they handle this case?

I guess that they already know more than we, the public, do. How can we be sure they will fix this issue in time and make sure those doing derivative work will also follow in time?

Let's say, if Red Hat can already prepare updates because they have access to some still secret information, how can the creators of all its clones, like Rocky, Alma, Oracle, CensOS and the like also provide updates in time?

[ThiefMaster]

Usually trusted people from mainstream Linux distributions have the proper contacts (and/or are on the proper private mailing lists) to receive patches and more information than the general public early enough. I can only assume that this is the case here as well....

[bagder]

The "distro people" I refer to above are the ones subscribed to the distros mailing list.

[stevenpackardblp]

Being one of those "distro people" maintaining an internal distribution for my company only, it would be beneficial if we could somehow get access to a patch that can be applied to the 8.3.0 source as soon as possible.

[jbeckers]

Any guidance on which versions are vulnerable, so we can start planning what to upgrade?

[bagder]

I'm sorry, but if I would give you that information it would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The "last several years" of versions is as specific as I can get.

[taladar]

I know you can't give any details before the fix is released but I assume from the way the post is phrased that you are not talking about a HIGH security flaw in some obscure protocol or similar corner of the code virtually nobody ever uses in a way that is exploitable but about something that would affect a significant percentage of the curl and libcurl user bases?

[bagder]

Every security flaw requires a set of conditions to apply for the problem to trigger. The pending security vulnerabilities are no different. I cannot comment on what that set is ahead of time.

The severity level is a blunt tool. This is a HIGH severity problem but there is still going to be a large chunk of users who will not be affected by these problems.

[conmurray]

@bagder Might I ask if you think this would also affect pycurl, python-pycurl etc?

Thanks in advance

Conor

[bagder]

Yes it will. In general terms: everything that uses libcurl could theoretically use libcurl in a way that triggers this vulnerability, assuming that the conditions apply and that a vulnerable libcurl version is used. Of course some/many users will also use libcurl without being able to trigger the vulnerability.

It is impossible for me to make affirmative statements about specific libcurl users now.

[davidfoerster]

In case you’re asking if the patch to libcurl will require a redistribution of pycurl: most distros ship pycurl with dynamic linkage of libcurl (rather than static linkage). In that case, pycurl would almost certainly benefit from the changes to the (dynamically linked) libcurl without repackaging/redistribution.

(I say “almost certainly” because the libcurl patch might introduce a relevant ABI change which would require changes to pycurl but I find that very unlikely since there’s no such notice in the OP above.)

[bagder]

There is no API nor ABI change in the coming curl release. Updating the shared libcurl library should be enough to fix this issue on all operating systems.

Then again there will also be countless docker (and similar) images that feature their own copies, so there will still be quite a large number of rebuilds necessary I bet.

[ThiefMaster]

Bullshit. OpenSSL did the same for example: https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html
Now go troll elsewhere.

[ThiefMaster]

Well "this one software project" is one of the most critical ones out there... And I think we all know that OpenSSL is far from perfect (even though I think they improved a lot over the last years) - but guess what ,everyone was happy that they announced it in advance so people could prepare to patch ASAP when the patch hit.

Do you seriously prefer to be surprised - maybe on your day off, away from a proper computer - with an urgent update you need to install, instead of knowing some days in advance that you may need to quickly install a patch on a given day?

[bagder]

@robertsdotpm if you cannot keep a good and productive tone in this discussion from now on, I will ban you from this repository

[andreadelfino]

Thank you for the pre-alerting! At this stage can you disclose the affected versions range? It's just 8.* branch (given that you're going to release 8.4.0) or also 7.* or so may require additional patches? It would be helpful to better understand the impacted surface.

[ThiefMaster]

#12026 (reply in thread)

[bagder]

A lot of people are reading this thread or subscribe to it for real information updates, not suffering through troll comments. Therefore, it is now locked from further commenting. If you have additional questions/comments about the pending release and associated security vulnerabilities, contact me or start a separate discussion thread

I have tried to move relevant information into the initial post to reduce the need to scroll through this page to find it.

[bagder]

The release, the CVEs, the advisories and associated blog posts are now all public. The post here is updated with some links.