[Daniel's week] October 13, 2023

[Daniel Stenberg]

Hello friends.

We made it another week.

## CVE

So this week we finally published the detailed of CVE-2023-38545 [1].

It of course started long before the publication with a range of alarming news 
articles and tweets talking about the pending announcement in terms as if it 
would be a significant event and I got the sense that people and media were 
overstating the pending advisory. That would of course be hard to for me to 
argue ahead of time. All I had said was that that it is a severity HIGH issue 
that is the worst curl security vulnerability in a long time. Which I still 
maintain is true. Looking back, the previous curl buffer overflow with a nasty 
attack opportunity is probably CVE-2019-3822 [2], but since that relies on 
NTLM authentication being used, it was possibly a narrower case to actually 
attack. We had some other bad flaws in 2018 that are probably at the same 
level as this new one. So the worst in 4-5 years at least.

But is it sky-falling bad? No, this is far from a new heartbleed or log4shell 
issue. It is a buffer overflow but one that is restricted in nature as it only 
affects users of SOCKS5h and it requires a malicious attacker on a site that a 
user "visits" over this proxy.

During the week leading up to the publication I got a steady stream of 
requests from big and small companies and organizations asking for early 
access to the CVE details. I stayed firm and repeatedly told everyone that I 
told the distros list and the only other option is to sign up for a curl 
support contract and have a good reason. At the end this might have actually 
given me one new customer, with a chance for one more in discussion. For me, 
it was a way to keep my head clear and have a consistent response that helped. 
Most people who asked of course I never heard from again. One of the big 
players of course had to email me after the publication only to question the 
severity level because according to them: "SOCKS is not widely used in the 
enterprise".

Late Tuesday evening, with about ten hours left until the publication was 
scheduled, I received several emails and messages when one of the vendors who 
had received the information merged the patch into their publicly accessible 
repository and suddenly it was available to the whole world. Given the amount 
of messages I received about it, the knowledge of this leak was fairly wide.

We had a discussion about it in the curl-security team but decided that the 
was such a small time window left until the planned release that doing a 
rushed early release would rather risk that we would do a mistake from our end 
and make a bad release, plus that lots of users already had their timers and 
expectations set for 06:00 UTC so a surprise release out of schedule could 
also risk just not being properly received. We therefore waited until the 
scheduled time before the release was made public.

The vendor behind the leak took it seriously and were genuinely sorry and 
expressed their apologies and intentions to work on making sure this will not 
happen again (in private emails with the curl team) and one of the persons 
behind the mistake sent a sincere apology [3] to the curl-library mailing 
list. There are of course no hard feeling here. We all know mistakes happen. 
We then need to learn from them, adapt and move on.

In preparation for the release of the CVE information, I wrote a 1500 word 
blog post about the flaw [4], what it is, how it works and how it ended up 
becoming a problem. Since I wrote the flaw, I was of course in a good position 
to explain the details. I am fully aware that what I and we in curl can offer 
than some other products and projects cannot and will not provide, is full and 
almost "extreme" transparency. This builds trust and it shows everyone that we 
take this seriously, but also that there is a human side to all this. And all 
humans do mistakes. In my mission to keep documentation and information in the 
curl project and about the curl project at a gold standard I figured it was 
nothing but the right thing to do. And after all, I did write the bug so there 
was no point in hiding or denying that fact. The warm feedback and amazing 
reception of this blog post warm my heart.

After the release shipped, there was of course second wave of media articles 
but now often with a tone of maybe "underwhelmed" commentary. It was not the 
end of the world event some people seemed to have hoped for. Lots of news 
articles of course also keep having a hard time to grasp that curl is a little 
more than a command line client for a few geeks.

To top things off and to add load to my week, my release stream got delayed by 
almost an hour. I started out by having OBS Studio repeatedly crash on me on 
my main machine and I figured it must have been because I dist-upgraded my 
Debian Unstable just the day before. I switched over to my laptop for doing an 
emergency stream from that machine, but the great people in the twitch chat 
informed me that the sound was choppy and in spite of many and extensive 
tweaks and configuration changes and microphone changes, I could not make the 
sound work correctly for the stream. I then switched to the third computer, my 
second laptop, a Windows one. I moved over the fancy microphone and connected 
it into the windows laptop... only to not to find it not getting the frame 
rate up correctly on the video feed. AAAAARGH. I switched back to my main 
development machine, uninstalled and and reinstalled obs and voila, the 
crashes from before were gone. I could start the stream, the audio and video 
were okay and I could *finally* stream and record my release video [4]. Phew.

Post release, we have received a few issues that have identified a few build 
related regressions in the 8.4.0 release, but right now we have not decided on 
if we should do a quick follow-up patch release or not. After all, most users 
do not build curl themselves or will run into these problems. To be decided.

## contributors

We reached 3,000 contributors to the curl project [8]. 40% of the contributors 
have authored commits. 65% of the authors only ever authored a single commit. 
A rather amazing number of people nonetheless methinks. If the rate trend 
continues, we should be able to reach 4,000 within the next four years!

## CNA

In the midst of this busy week, long time curl regular and friend Jim Fuller 
and me had a meeting with Red Hat representatives in our project "curl 
becoming a CNA". It went fine and we are progressing fine. I hope and expect 
us to get through the formalities within the next few weeks. Hopefully, if we 
need and CVE Ids for the next curl release, we should be able to manage them 
ourselves.

There is no monetary fees for this and there is not a lot of formalities 
involved. Since we only will manage CVEs for curl itself, this should not add 
a lot of extra work but might help us get better control of and saying about 
curl CVEs going forward. I am not really a fan of every project having to 
become their own CNA, but I also do not see any other way to address our own 
CVE issues in the short to medium-long term. There is lots of talk in various 
forums on how to improve CVEs and the processes around them, but they are 
mostly for long term improvements that may or may not happen and they might 
take a long time to trickle down and actually improve our reality for real.

## sustain

In a nicely synced publication, the Sustain podcast published episode 203 [5] 
in which I talked with host Richard Littauer about the "bogus CVE" from a few 
weeks ago. How I got to learn about it, how I tried to reject it, how I argued 
with the NVD to downgrade it etc.

## c-ares release(s)

On Saturday October 7th I packaged, signed and uploaded c-ares 1.20.0 [6]. 
These days my activities in the c-ares project are mostly limited to 
occasional PR reviews and release management. All the heavy lifting the last 
years is done by Brad House. This release was no different.

Unfortunately, a rather ugly bug was included in that release, which then 
subsequently allowed me to rerun the procedure again on the Sunday when we 
released c-ares 1.20.1 with the fix! The fun never ends.

## next level curl

I got a reminder this week that I am keynoting the Platform Summit 2023 
conference next week here in Stockholm when an email on Wednesday afternoon 
informed me that the organizers want my presentation sent to them no later 
than Friday afternoon. And I had not started making the slides yet.

I name the talk "next level curl" and my plan is to highlight "fun things" we 
have introduced to the curl command line tool the last maybe four-five years. 
As way to remind everyone what goodies you can get and use and do if you just 
make sure you keep up with modern curl releases. In only thirty minutes. As I 
type this on late Friday afternoon, most of the presentation is done and I 
have a pretty good sense for getting the rest in shape.

## libcurl video

I still plan on doing a long mastering libcurl presentation in November in the 
style of the mastering the curl command line video [7], but I feel a little 
behind in my planning and creation of the slides etc so I will hold off on 
giving a date for this event just yet. Once I start to get a better idea of 
the scope and the topics I want to include, I will do an introductory blog 
post about the event to also allow the curl community to tell what else to add 
to the agenda. Hopefully that blog post can go out within a week or two.

## Coming up

- patch release maybe?
- Next level curl talk on Wednesday

## Links

[1] = https://curl.se/docs/CVE-2023-38545.html
[2] = https://curl.se/docs/CVE-2019-3822.html
[3] = https://curl.se/mail/lib-2023-10/0021.html
[4] = https://daniel.haxx.se/blog/2023/10/11/how-i-made-a-heap-overflow-in-curl/
[5] = https://podcast.sustainoss.org/203
[6] = https://c-ares.org/download/
[7] = https://youtu.be/V5vZWHP-RqU
[8] = https://daniel.haxx.se/blog/2023/10/13/3000-contributors/


-- 

  / daniel.haxx.se