[Daniel's week] October 6, 2023

[Daniel Stenberg]

Hello friends.

This was an intense week. Now I'm taking weekend!

## CVE

We get a fair amount of suspected security vulnerabilities reported to us,
partly of course because of the promise of paying good money for them if they
are real. On Saturday yet another report landed in our system but it did not
take long time to confirm that this was not the ordinary "gold digger"
report. This was a genuine curl security vulnerability. One of those reports
that really wakes you up an otherwise relaxed and comfortable Saturday
morning. It really burns in my soul. And honestly, it made my entire week
quite different and more intense than I previously expected it to become.

The high quality report came from a trusted old-timer in the project and it
was easy to spot that it was accurate and valid. But how serious is it? It
took some bouncing back and forth in the team to make up our minds, and while
we started to draft the advisory we decided to do an early release for this
and we told the curl mailing list [1] about it on Monday. I later followed up
with announcing that same news on Mastodon [2], Twitter [3] and LinkedIn
[4]. The ball started rolling.

This case is fortunately one of those that took hard work to find and analyze,
but once the error is spotted fixing it is actually fairly straight-forward so
at least we did not have to struggle with this part a lot.

We landed on it being severity HIGH (taking it down from the CRITICAL level we
first discussed), which we have not done for a curl security vulnerability for
almost 2.5 years. To find a past security problem with the same or worse
theoretical impact, we have to go back several more years.

On Tuesday, I emailed the *distros* mailing list, notifying them about this
pending security announcement (plus a second CVE we set severity LOW on).
Subscribed to that mailing list are representatives from open source Linux and
BSD distributions. This allows them to prepare and line up patched (lib)curl
releases aligned with the public release of curl 8.4.0 on October 11.

I collected the info I was able to share with the public in a GitHub
discussion [5] and made an "alert" thing at the top of most pages on the curl
website that mentions the pending security fix.

Those social media posts of mine about CVE-2023-38545 got a fair bit of
attention. I was soon getting emailed by organizations and large companies
asking me to get "let in" on the secrets they had learned are coming.

To restrict the distribution of the details around this vulnerability, and to
keep a tight lid on the information flow, I decided to set the bar high. I
don't want to later learn that any random Joe figured out the specifics ahead
of time because of (my) sloppy infosec somewhere. There are therefore only two
ways to get to know curl vulnerability details before the general public: the
distros mailing list or by having a curl support contract plus a good
motivation why you need to know. Those who are not in one of those two groups
are flat out denied the information. Having a policy and sticking to it made
it easier for me to respond as more begging emails arrived.

The advisory is almost written now and contains plenty of details. I also have
a pending 1,500 word blog post explaining more background and insight into
exactly how this flaw happened.

The next-level requests for info arrived today, asking specifically if company
X and Y has received the vulnerability details ahead of time or not, with the
expectation that if not, they might be slower than others to provide updates
after the release. I decided to not provide that info. It is not my job to
snitch.

## Interview

In the midst of my CVE storm week, an interview I did previously went public
[6]. It sits on nordicapis.com, hosts of a conference here in Stockholm at
which I will do a keynote in two weeks.

## ECH

This week Firefox announced [7] that it joins Chrome [9] and offers ECH
support to users. ECH is short for Encrypted Client Hello [10] and allows
clients doing TLS to avoid sending the target host name in clear text. The TLS
SNI field is otherwise a data point that is easy to track and to spot to which
hosts individual TLS connections are made to. By your ISP or anyone else who
sits on the path between the client and the server machine in the other end.

Quite timely, Stephen Farrell has a PR for curl in the works [8] to introduce
ECH support. It is not quite there yet, and if it hadn't been for me having to
rush out an extra release soon I would probably have provided more feedback on
that PR this week.

ECH needs data from DNS, which adds complexity because you want the client to
be able trust the data and you prefer that data to be fetched encrypted, like
with DoH. For now, it seems most implementations therefore require DoH in
order to use ECH, which of course limits the use somewhat. Still a good first
step I think.

## c-ares

Brad House has been doing great work and lots of clean ups in the c-ares
project [11] recently and there is now a new release pending there. I will get
around and make that asap, likely during this coming weekend. Stay tuned!

## Coming up

- c-ares release this weekend
- curl CNA onboarding meeting Tuesday
- curl release Wednesday

## Links

[1] = https://curl.se/mail/lib-2023-10/0002.html
[2] = https://mastodon.social/@bagder/111167662713737288
[3] = https://twitter.com/bagder/status/1709103920914526525
[4] = https://www.linkedin.com/posts/danielstenberg_curl-activity-7114871742585577472-4OuW
[5] = https://github.com/curl/curl/discussions/12026
[6] = https://nordicapis.com/interview-with-curl-founder-daniel-stenberg/
[7] = https://blog.mozilla.org/en/products/firefox/encrypted-hello/
[8] = https://github.com/curl/curl/pull/11922
[9] = https://chromestatus.com/feature/6196703843581952
[10] = https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni
[11] = https://c-ares.org/


-- 

  / daniel.haxx.se