From eb5391d56ae9c18029a9c66549b5d007a725a830 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Wed, 6 Nov 2024 08:12:21 +0100 Subject: [PATCH] CVE-2024-9681.md: HSTS subdomain overwrites parent cache entry --- docs/CVE-2024-9681.md | 114 ++++++++++++++++++++++++++++++++++++++++++ docs/Makefile | 3 +- docs/vuln.pm | 1 + 3 files changed, 117 insertions(+), 1 deletion(-) create mode 100644 docs/CVE-2024-9681.md diff --git a/docs/CVE-2024-9681.md b/docs/CVE-2024-9681.md new file mode 100644 index 0000000000..c47d71aecc --- /dev/null +++ b/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! diff --git a/docs/Makefile b/docs/Makefile index ae325f0ef4..61b2133223 100644 --- a/docs/Makefile +++ b/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) \ diff --git a/docs/vuln.pm b/docs/vuln.pm index 0ca88462aa..c7daa1f88e 100644 --- a/docs/vuln.pm +++ b/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",