[Daniel's week] December 8, 2023

[Daniel Stenberg]

Hello,

Friday meens another weekly summary!

## release

I followed the release checklist carefully and shipped curl 8.5.0 [8] on
Wednesday morning exactly as planned. I shared the details for the new
vulnerabilities and I did the release video live-stream. The stream turned out
a little different than usual because obs studio decided to crash on me
instantly when I try to share a window, so I had to rearrange it a little and
instead share a full screen to work around the issue and still be able to
present something.  Something I need to get fixed in time for the next stream
I guess because this was not ideal.

The release was not the best one this time either as we got an early bugreport
[2] that showed that the release tarballs lack a file - a script really - that
makes a recently create test case always fail. We of course will check why
this CI builds missed this and we have fixed the problem in git. It has not
yet been decided if this is enough to warrant a patch release but my gut
feeling says no. If there are not worse problems reported within the coming
week I think we can live with this and rather aim for a full release cycle
until we ship. The scheduled next release date is January 31, 2024.

## CVEs

The two security vulnerabilities we announced this time were both fairly
harmless. Both Hakerone reports have been disclosed so that you can check out
our work, communication and process from the very first report to us until we
published them. See CVE-2023-46219: HSTS long file name clears contents [3]
and CVE-2023-46218: cookie mixed case PSL bypass [4].

Neither of these problems is what I categorize as a "C problem" (a mistake
that likely would not have happened if we would use a memory-safe
language). We are now at a total of 150 reported CVEs through the project
history. Just over 40% of them are due to C mistakes. The share of C mistakes
among the reported vulnerabilities in curl has in fact been shrinking
continuously since its peak in 2019 [5]. Note that this graph is per the
*report date*. If we instead check the graph that is based on the date where
the flaw was *introduced* [6], we can see that the share of C mistakes present
in the code has actually never been above 50% of the total.

Of course, if we would limit the data to only high or critical
vulnerabilities, we might see a different story. I will probably enjoy myself
by making some new graphs for that purpose soon.

## cpy and alloc calls

Classic buffer overflow mistakes in C code usually involve using one of the
functions memcpy, strcpy or strncpy - the `*cpy` calls. In curl, we have over
time introduced many helper functions that make the need for using such cpy
functions less prevelant. An idea being that it might also then over time make
the code better and hard to do buffer mistakes with. This week I merged a new
round of code cleanups where I found corners of the source code where we could
clean up code paths and reduce the number of such cpy calls [7].

Right now in git master, the lib/ directory tree has 260 matches for
'(mem|str|strn)cpy', out of 137,773 lines of code (including comments). One
cpy call for every 529 lines of code.

Some quick history checks for the same stuff:

- In 7.81.0 we had 299 cpy calls in 125,694 lines of code: one cpy call for
every 420 lines of code.

- In 7.69.1 we had 288 cpy calls in 116,551 lines of code: one cpy call for
every 404 lines of code.

- In 7.52.1 we had 234 cpy calls in 98,341 lines of code: one cpy call for
every 420 lines of code.

Another common area of mistakes in C code is related to allocating memory and
using (temporary) heap buffers. In particular everything that has to do with
realloc(). We therefore work on reducing such calls as well - and instead use
common helper functions.

Right now in git master, the lib/ directory has 297 matches for
'(m|re|c)alloc\('. One alloc call per 463 lines of code.

- 7.81.0: one per 409 lines of code

- 7.69.1: one per 377 lines of code

- 7.52.1: one per 362 lines of code

## audit

We have another curl code audit coming up. It is again sponsored and organized
via OSTIF and this time the focus is on and limited to curl's HTTP/3
components. The scope is what the OSTIF sponsor (who still is unknown to me)
has asked for and I think it seems suitably timely since we just this week
shipped the first curl release ever with HTTP/3 support no longer being just
experimental.

As you might recall, curl supports HTTP/3 using one out of (currently) three
different backends but only the ngtcp2+nghttp3 backend is considered
non-experimental so far. Those two libraries only just recently left their
beta phases, in which they have been for several years.

I have no doubts that there might be details to find and possible issues to
address in this area, perhaps in particular in the interactions between the
multiple libraries and in how they are used and not used etc. Perhaps also
because HTTP/3 has not been used much in production with curl up until now so
there is likely to still exist a few rough corners we better polish off.

This audit is going to be performed by Trail of Bits. The same company who did
our previous code audit, published at the end of 2022. Links to their previous
audit reports from then cam be found on the curl security page[1].

The audit kick-off meeting happens today.

## Coming up

  - the HTTP/3 code audit

## Links

[1] = https://curl.se/docs/security.html
[2] = https://github.com/curl/curl/issues/12462
[3] = https://hackerone.com/reports/2236133
[4] = https://hackerone.com/reports/2212193
[5] = https://curl.se/dashboard1.html#c-reports
[6] = https://curl.se/dashboard1.html#c-vulns
[7] = https://github.com/curl/curl/pull/12453
[8] = https://daniel.haxx.se/blog/2023/12/06/curl-8-5-0/

-- 

  / daniel.haxx.se