curl: CVE-2024-2379: QUIC certificate check bypass with wolfSSL

Summary:

In vquic-tls.c curl_wssl_init_ctx errors are handled by goto out and having result be set to an error code to be returned. At the beginning of the function result is correctly set to CURLE_FAILED_INIT which allows for goto out to work correctly without having to set result however, result’s value is overridden at a certain point if ctx_setup is passed to the function. If ctx_setup returns 0 (the expected result) then it’s assigned to result and any attempt after that to goto out without setting result to an error code will make the function skip the rest of its initialization and return with an error code indicating success.

Unfortunately the last thing curl_wssl_init_ctx is supposed to setup for the ssl context is the certificate verification requirements. There are 4 places goto out is used without setting result, of those 3 can result from bad user input (bad tls13-ciphers, curves, or cafile/capath) and 1 is from trying to setup ssl key logging when having a WolfSSL build that doesn’t have wolfSSL_CTX_set_keylog_callback.

Luckily this does require the user to have passed in bogus values for one of the above parameters which I find very unlikely. Also very fortunately WolfSSL attempts to default to verify a cert rather than OpenSSL’s default of not verifying. There is an option to make WolfSSL have OpenSSL compatible defaults but I don’t know how common it is to have WolfSSL configured like that so I’m not sure how likely it is that people could run into this.

Given the unlikely set of configurations required to encounter this I don’t think this is a “high” vulnerability like the CVSS claims but there is no way of manually setting the score, honestly I would have just submitted a patch to fix this but I’m not to sure on how common having WolfSSL in OpenSSL compatible mode is so I’m err’ing on the side of caution and submitting it here.

I checked the other initialization functions in vquic-tls.c and it doesn’t look like the same mistake was made in them. result is assigned before each use of goto out.

Steps To Reproduce:

Build WolfSSL with something that sets OPENSSL_COMPATIBLE_DEFAULTS (I used --enable-nginx) and build curl with the WolfSSL backend.
Setup a QUIC webserver with a self signed cert that matches the domain being spoofed and attempt to make a HTTP/3 connection to it using curl with a bad --curves list. curl connects to the site without having set --insecure, taking out the bad --curves argument curl will complain about the invalid cert.

ex:

./curl -v --http3-only 'https://example.com/' -o /dev/null -s --resolve example.com:443:192.168.1.24 --curves blah
* Added example.com:443:192.168.1.24 to DNS cache
* Hostname example.com was found in DNS cache
*   Trying 192.168.1.24:443...
* wolfSSL failed to set curves
* Verified certificate just fine
* Connected to example.com (192.168.1.24) port 443
* using HTTP/3
* [HTTP/3] [0] OPENED stream for https://example.com/
* [HTTP/3] [0] [:method: GET]
* [HTTP/3] [0] [:scheme: https]
* [HTTP/3] [0] [:authority: example.com]
* [HTTP/3] [0] [:path: /]
* [HTTP/3] [0] [user-agent: curl/8.7.0-DEV]
* [HTTP/3] [0] [accept: */*]
> GET / HTTP/3
> Host: example.com
> User-Agent: curl/8.7.0-DEV
> Accept: */*
> 
* We are completely uploaded and fine
< HTTP/3 200 
< server: nginx/1.25.4
< date: Sun, 10 Mar 2024 21:02:39 GMT
< content-type: text/html
< content-length: 615
< last-modified: Wed, 14 Feb 2024 16:03:00 GMT
< etag: "65cce434-267"
< accept-ranges: bytes
< 
{ [615 bytes data]
* Connection #0 to host example.com left intact

vs

./curl -v --http3-only 'https://example.com/' -o /dev/null -s --resolve example.com:443:192.168.1.24 
* Added example.com:443:192.168.1.24 to DNS cache
* Hostname example.com was found in DNS cache
*   Trying 192.168.1.24:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* QUIC connect to 192.168.1.24 port 443 failed: SSL peer certificate or SSH remote key was not OK
* Failed to connect to example.com port 443 after 12 ms: SSL peer certificate or SSH remote key was not OK
* Closing connection

Supporting Material/References:

This was introduced in https://github.com/curl/curl/pull/12678 so the only vulnerable version to be released is 8.6.0

Impact

If the stars align and the user is using such a configuration and passing bad arguments then they would be vulnerable to MITM attacks.