CVE-2022-43551: Another HSTS bypass via IDN

How it was found

Summary:

I found an issue similar to CVE-2022-42916 again. Since the phenomenon is the same, I will describe the same as last time.

HSTS checks are bypassed if any character in the IDN convert(Nameprep) to a '.' for example"。"(UTF-8:E38082). I think there are other characters that become ".(UTF-8:2E)" as a result of converting with IDN.

This is because the host name before IDN conversion is used when writing to the HSTS cache.

Steps To Reproduce:

[add details for how we can reproduce the issue]

1. Start from a state where there is no entry for the access destination host name in the HSTS cache
2. curl -v --hsts hsts.txt https://accounts.google%E3%80%82com
3. curl -v --hsts hsts.txt http://accounts.google%E3%80%82com

Result of 3.

C:\test\curl-7.86.0-win64-mingw\bin>curl -v --hsts hsts.txt http://accounts.google%E3%80%82com --head
*   Trying 142.250.206.237:80...
* Connected to accounts.google縲Ｄom (142.250.206.237) port 80 (#0)
> HEAD / HTTP/1.1
> Host: accounts.google.com
> User-Agent: curl/7.86.0
> Accept: */*
>

If you execute 3. after executing the below, you will access the site with HTTPS. curl -v --hsts hsts.txt https://accounts.google.com

I use this in a Windows environment.

I checked the HSTS cache after executing 2. and found the host name before IDN conversion.

# Your HSTS cache. https://curl.se/docs/hsts.html
# This file was generated by libcurl! Edit at your own risk.
.accounts.google。com "20231029 15:57:29"

I think the problem is in http.c:line 3727. data->state.up.hostname is the hostname of the IDN unconverted.

    CURLcode check =
      Curl_hsts_parse(data->hsts, data->state.up.hostname,
                      headp + strlen("Strict-Transport-Security:"));

Impact

HSTS bypass.