CVE-2024-9681.md: HSTS subdomain overwrites parent cache entry

docs/CVE-2024-9681.md

@@ -0,0 +1,114 @@
+HSTS subdomain overwrites parent cache entry
+============================================
+
+Project curl Security Advisory, November 6th 2024 -
+[Permalink](https://curl.se/docs/CVE-2024-9681.html)
+
+VULNERABILITY
+-------------
+
+When curl is asked to use HSTS, the expiry time for a subdomain might
+overwrite a parent domain's cache entry, making it end sooner or later than
+otherwise intended.
+
+This affects curl using applications that enable HSTS and use URLs with the
+insecure `HTTP://` scheme and perform transfers with hosts like
+`x.example.com` as well as `example.com` where the first host is a subdomain
+of the second host.
+
+(The HSTS cache either needs to have been populated manually or there needs to
+have been previous HTTPS accesses done as the cache needs to have entries for
+the domains involved to trigger this problem.)
+
+When `x.example.com` responds with `Strict-Transport-Security:` headers, this
+bug can make the subdomain's expiry timeout *bleed over* and get set for the
+parent domain `example.com` in curl's HSTS cache.
+
+The result of a triggered bug is that HTTP accesses to `example.com` get
+converted to HTTPS for a different period of time than what was asked for by
+the origin server. If `example.com` for example stops supporting HTTPS at its
+expiry time, curl might then fail to access `http://example.com` until the
+(wrongly set) timeout expires. This bug can also expire the parent's entry
+*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier
+than otherwise intended.
+
+INFO
+----
+
+When triggered, this is a potential minor DoS security problem when trying to
+use HTTPS when that no longer works or a cleartext transmission of data that
+was otherwise intended to *possibly* be protected.
+
+But:
+
+`example.com` as per above is deliberately setup for HSTS, and servers should
+probably expect that clients will try upgrading to HTTPS for a while outside
+of the time range set in its headers.
+
+The access that fails in this scenario tries to use plain HTTP to the domain.
+Clear text, unprotected, vulnerable. HTTP is an insecure protocol and as such
+applications should **not** rely on nor trust such responses, which reduces
+the severity of this issue.
+
+Even without this problem, servers occasionally set HSTS headers but have
+problems with their HTTPS offering so this is a scenario that an application
+ends up in now and then completely without involving curl issues and therefore
+needs to have logic for. An application can for example work around the
+situation by simply toggling off HSTS.
+
+This bug is **not** considered a *C mistake* (ie not likely to have been
+avoided had we not been using C).
+
+This flaw also affects the curl command line tool.
+
+The Common Vulnerabilities and Exposures (CVE) project has assigned the name
+CVE-2024-9681 to this issue.
+
+CWE-1025: Comparison Using Wrong Factors
+
+Severity: Low
+
+AFFECTED VERSIONS
+-----------------
+
+The vulnerable code can only be reached when curl is told to use HSTS.
+
+- Affected versions: curl 7.74.0 to and including 8.10.1
+- Not affected versions: curl < 7.74.0 and >= 8.11.0
+- Introduced-in: https://github.com/curl/curl/commit/7385610d0c74c6a25
+
+libcurl is used by many applications, but not always advertised as such!
+
+SOLUTION
+------------
+
+- Fixed-in: https://github.com/curl/curl/commit/a94973805df96269bf
+
+RECOMMENDATIONS
+---------------
+
+We suggest you take one of the following actions immediately, in order of
+preference:
+
+ A - Upgrade curl and libcurl to version 8.11.0
+
+ B - Apply the patch to your version and rebuild
+
+ C - Avoid relying on HSTS
+
+TIMELINE
+---------
+
+This issue was reported to the curl project on October 7, 2024. We contacted
+distros@openwall on October 29, 2024.
+
+curl 8.11.0 was released on November 6 2024 around 06:00 UTC, coordinated with
+the publication of this advisory.
+
+CREDITS
+-------
+
+- Reported-by: newfunction
+- Patched-by: Daniel Stenberg
+
+Thanks a lot!

docs/Makefile

@@ -178,7 +178,8 @@ CVELIST = \
  CVE-2024-6197.html \
  CVE-2024-6874.html \
  CVE-2024-7264.html \
- CVE-2024-8096.html
+ CVE-2024-8096.html \
+ CVE-2024-9681.html
 
 PAGES = \
  $(CVELIST) \

docs/vuln.pm

@@ -16,6 +16,7 @@
 #
 # List of CWEs => https://cwe.mitre.org/data/definitions/658.html
 @vuln = (
+    "CVE-2024-9681.html|7.74.0|8.10.1|HSTS subdomain overwrites parent cache entry|CVE-2024-9681|20241105|20241007|CWE-1025: Comparison Using Wrong Factors|540|HSTS|-|both|low|https://hackerone.com/reports/2764830",
     "CVE-2024-8096.html|7.41.0|8.9.1|OCSP stapling bypass with GnuTLS|CVE-2024-8096|20240911|20240819|CWE-295: Improper Certificate Validation|2540|TLS|-|both|medium|https://hackerone.com/reports/2669852",
     "CVE-2024-7264.html|7.32.0|8.9.0|ASN.1 date parser overread|CVE-2024-7264|20240731|20240730|CWE-125: Out-of-bounds Read|540|ASN1|OVERREAD|both|low|https://hackerone.com/reports/2629968",
     "CVE-2024-6874.html|8.8.0|8.8.0|macidn punycode buffer overread|CVE-2024-6874|20240724|20240716|CWE-126: Buffer Over-read|540|IDN|OVERREAD|lib|low|https://hackerone.com/reports/2604391",