[SECURITY ADVISORY] curl: CVE-2024-0853 : OCSP verification bypass with TLS session reuse

2024-01-30 Thread Daniel Stenberg via curl-library

OCSP verification bypass with TLS session reuse
===

Project curl Security Advisory, January 31 2024 -
[Permalink](https://curl.se/docs/CVE-2024-0853.html)

VULNERABILITY
-

curl inadvertently kept the SSL session ID for connections in its cache even
when the verify status (*OCSP stapling*) test failed. A subsequent transfer to
the same hostname could then succeed if the session ID cache was still fresh,
which then skipped the verify status check.

INFO


This issue is limited to curl built to use OpenSSL and when using TLS 1.2 only
and not TLS 1.3.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2024-0853 to this issue.

CWE-299: Improper Check for Certificate Revocation

Severity: Low

AFFECTED VERSIONS
-

- Affected versions: curl 8.5.0 to and including 8.5.0
- Not affected versions: curl < 8.5.0 and >= 8.6.0
- Introduced-in: https://github.com/curl/curl/commit/395365ad2d9a6c3f1a35d

libcurl is used by many applications, but not always advertised as such!

This flaw is also accessible using the curl command line tool.

SOLUTION


If verify status fails, make sure the session id is not cached.

- Fixed-in: https://github.com/curl/curl/commit/c28e9478cb2548848ec

RECOMMENDATIONS
--

 A - Upgrade curl to version 8.6.0

 B - Apply the patch to your local version

 C - Do not use curl built to use OpenSSL

 D - Do not allow TLS 1.2 for your transfers

TIMELINE


This issue was reported to the curl project on December 29, 2023. We contacted
distros@openwall on January 24, 2024.

curl 8.6.0 was released on January 31 2024 around 07:00 UTC, coordinated with
the publication of this advisory.

CREDITS
---

- Reported-by: Hiroki Kurosawa
- Patched-by: Daniel Stenberg

Thanks a lot!

--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


[RELEASE] curl 8.6.0

2024-01-30 Thread Daniel Stenberg via curl-library

Hello!

Welcome to a new curl release! Get it as always from https://curl.se/

curl and libcurl 8.6.0

 Public curl releases: 254
 Command line options: 258
 curl_easy_setopt() options:   304
 Public functions in libcurl:  93
 Contributors: 3078

This release includes the following changes:

 o add CURLE_TOO_LARGE [48]
 o add CURLINFO_QUEUE_TIME_T [76]
 o add CURLOPT_SERVER_RESPONSE_TIMEOUT_MS: add [39]
 o asyn-thread: use GetAddrInfoExW on >= Windows 8 [55]
 o configure: make libpsl detection failure cause error [109]
 o docs/cmdline: change to .md for cmdline docs [77]
 o docs: introduce "curldown" for libcurl man page format [102]
 o runtests: support -gl. Like -g but for lldb. [47]

This release includes the following bugfixes:

 o altsvc: free 'as' when returning error [23]
 o appveyor: replace PowerShell with bash + parallel autotools [54]
 o appveyor: switch to out-of-tree builds [29]
 o asyn-ares: with modern c-ares, use its default timeout [127]
 o build: delete unused `HAVE_{GSSHEIMDAL,GSSMIT,HEIMDAL}` [4]
 o build: delete/replace clang warning pragmas [111]
 o build: enable missing OpenSSF-recommended warnings, with fixes [11]
 o build: fix `-Wconversion`/`-Wsign-conversion` warnings [26]
 o build: fix Windows ADDRESS_FAMILY detection [35]
 o build: more `-Wformat` fixes [40]
 o build: remove redundant `CURL_PULL_*` settings [8]
 o cf-h1-proxy: no CURLOPT_USERAGENT in CONNECT with hyper [133]
 o cf-socket: show errno in tcpkeepalive error messages [120]
 o CI/distcheck: run full tests [31]
 o cmake: add option to disable building docs
 o cmake: fix generation for system name iOS [53]
 o cmake: fix typo [5]
 o cmake: freshen up docs/INSTALL.cmake [101]
 o cmake: prefill/cache `HAVE_STRUCT_SOCKADDR_STORAGE` [45]
 o cmake: rework options to enable curl and libcurl docs [161]
 o cmake: when USE_MANUAL=YES, build the curl.1 man page [113]
 o cmdline-opts/write-out.d: remove spurious double quotes
 o cmdline-opts: update availability for the *-ca-native options [66]
 o cmdline/gen: fix the sorting of the man page options [33]
 o configure: add libngtcp2_crypto_boringssl detection [155]
 o configure: fix no default int compile error in ipv6 detection [69]
 o configure: when enabling QUIC, check that TLS supports QUIC [87]
 o connect: remove margin from eyeballer alloc [79]
 o content_encoding: change return code to typedef'ed enum [94]
 o cookie.d: document use of empty string to enable cookie engine [106]
 o cookie: avoid fopen with empty file name [24]
 o curl.h: CURLOPT_DNS_SERVERS is only available with c-ares [131]
 o curl: show ipfs and ipns as supported "protocols" [15]
 o curl_easy_getinfo.3: remove the wrong time value count [116]
 o curl_multi_fdset.3: remove mention of null pointer support [134]
 o CURLINFO_REFERER.3: clarify that it is the *request* header [70]
 o CURLOPT_AUTOREFERER.3: mention CURLINFO_REFERER
 o CURLOPT_POSTFIELDS.3: fix incorrect C string escape in example [27]
 o CURLOPT_SSH_*_KEYFILE: clarify [57]
 o dist: add tests/errorcodes.pl to the tarball [6]
 o docs: clean up Protocols: for cmdline options [32]
 o docs: describe and highlight super cookies [80]
 o docs: do not start lines/sentences with So, But nor And [140]
 o docs: install curl.1 with cmake [166]
 o docs: mention env vars not used by schannel [124]
 o doh: remove unused local variable [34]
 o examples: add four new examples [99]
 o file+ftp: use stack buffers instead of data->state.buffer [138]
 o ftp: handle the PORT parsing without allocation [44]
 o ftp: use dynbuf to store entrypath [83]
 o ftp: use memdup0 to store the OS from a SYST 215 response [82]
 o ftpserver.pl: send 213 SIZE response without spurious newline
 o gen.pl: support ## for doing .IP in table-like lists [105]
 o gen: do italics/bold for a range of letters, not just single word [78]
 o GHA: add a job scanning for "bad words" in markdown [164]
 o GHA: bump ngtcp2, gnutls, mod_h2, quiche [158]
 o gnutls: fix build with --disable-verbose [3]
 o haproxy-clientip.d: document the arg [68]
 o headers: make sure the trailing newline is not stored [97]
 o headers: remove assert from Curl_headers_push [115]
 o hostip: return error immediately when Curl_ip2addr() fails [19]
 o hsts: remove assert for zero length domain [96]
 o http2: improved on_stream_close/data_done handling [49]
 o http3/quiche: fix result code on a stream reset [91]
 o http3: initial support for OpenSSL 3.2 QUIC stack [110]
 o http: adjust_pollset fix [85]
 o http: check for "Host:" case insensitively [154]
 o http: fix off-by-one error in request method length check [14]
 o http: only act on 101 responses when they are HTTP/1.1 [98]
 o http: remove comment reference to a removed solution [156]
 o http: use stack scratch buffer [150]
 o http_proxy: a blank CURLOPT_USERAGENT should not be used in CONNECT [90]
 o krb5: add prototype to silence clang warnings on mvsnprintf() [119]
 o lib: add debug log outputs for CURLE_BAD_FUNCTION_ARGUMENT [62]
 o 

Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread mos via curl-library
Why to use valgrind? Instruments shows the leaks. Also, if I calls this code in 
a loop, the memory of the process raise for every call,


Sent from my iPhone

> On 31 Jan 2024, at 4:06, Calvin Buckley via curl-library 
>  wrote:
> 
> On Jan 30, 2024, at 6:56 PM, Josh WizardGuy via curl-library 
>  wrote:
>> U. Use valgrind? 🤷
> 
> That would be great advice... if Valgrind supported macOS/arm64.
> -- 
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread Calvin Buckley via curl-library
On Jan 30, 2024, at 6:56 PM, Josh WizardGuy via curl-library 
 wrote:
> U. Use valgrind? 🤷

That would be great advice... if Valgrind supported macOS/arm64.
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread Josh WizardGuy via curl-library
U. Use valgrind? 🤷

On Tue, Jan 30, 2024, 11:39 AM Mos Yud via curl-library <
curl-library@lists.haxx.se> wrote:

> Hi,
>
> Machine: M1 sonoma 14.1.1
>
> At my test I am using the shipped lib of curl, and its default used SSL,
> that is:
> curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport)
> LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1
>
> I am getting memory leaks while running the following test:
>
> *void* CallCurl() {
>
> CURL *hnd;
>
> hnd = curl_easy_init();
>
> curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);
>
> curl_easy_perform(hnd);
>
> curl_easy_cleanup(hnd);
>
> }
>
> I track the leaks with macOS instruments, and I see that all leaks are
> from SSL (I am using the default SSL that the shipped curl uses).
>
> Examples for the leaks stack frames:
> 1.
> serialize_ECPublicKey
> ECDSA_do_verify_new
> ossl_ecdsa_verify
> EVP_DigestVerifyFinal
> tls13_server_certificate_verify_recv
> tls13_handshake_perform
> tls13_legacy_connect
> ossl_connect_common
> ssl_cf_connect
> cf_setup_connect
> cf_hc_connect
> Curl_conn_connect
> multi_runsingle
> curl_multi_perform
> curl_easy_perform
> CallCurl()
> main
> start
>
> 2.
> ccMallocECCryptor
> CCECCryptorImportKey
> ECDSA_do_verify_new
> ossl_ecdsa_verify
> EVP_DigestVerifyFinal
> tls13_server_certificate_verify_recv
> tls13_handshake_perform
> tls13_legacy_connect
> ossl_connect_common
> ssl_cf_connect
> cf_setup_connect
> cf_hc_connect
> Curl_conn_connect
> multi_runsingle
> curl_multi_perform
> curl_easy_perform
> CallCurl()
> main
> start
>
> 3.
> ccMallocECCryptor
> CCECCryptorImportKey
> ECDSA_do_verify_new
> ossl_ecdsa_verify
> EVP_DigestVerifyFinal
> tls13_server_certificate_verify_recv
> tls13_handshake_perform
> tls13_legacy_connect
> ossl_connect_common
> ssl_cf_connect
> cf_setup_connect
> cf_hc_connect
> Curl_conn_connect
> multi_runsingle
> curl_multi_perform
> curl_easy_perform
> CallCurl()
> main
> start
>
> Any advice?
>
> Thx,
> Moshe.
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html
>
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread Mos Yud via curl-library
I didn't check it since I assumed I linked only with libcurl.dylib. If i
use this call, i need to link also with openssl.
According to curl documentation curl_easy_cleanup should clean all memory,
and its sounds strange that macOS is shifted with a curl that expose memory
leaks.
I also tested with curl 8.5.0 (aarch64-apple-darwin23.1.0) libcurl/8.5.0
SecureTransport zlib/1.2.12, and didn't see these leaks.

On Tue, Jan 30, 2024 at 9:59 PM Ray Satiro via curl-library <
curl-library@lists.haxx.se> wrote:

> On 1/30/2024 11:39 AM, Mos Yud via curl-library wrote:
>
> Machine: M1 sonoma 14.1.1
>
> At my test I am using the shipped lib of curl, and its default used SSL,
> that is:
> curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport)
> LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1
>
> I am getting memory leaks while running the following test:
>
> *void* CallCurl() {
>
> CURL *hnd;
>
> hnd = curl_easy_init();
>
> curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);
>
> curl_easy_perform(hnd);
>
> curl_easy_cleanup(hnd);
>
> }
>
> I track the leaks with macOS instruments, and I see that all leaks are
> from SSL (I am using the default SSL that the shipped curl uses).
>
>
> What happens if you call OPENSSL_cleanup() before exit?
>
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html
>
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread Ray Satiro via curl-library

On 1/30/2024 11:39 AM, Mos Yud via curl-library wrote:

Machine: M1 sonoma 14.1.1

At my test I am using the shipped lib of curl, and its default used 
SSL, that is:
curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport) 
LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1


I am getting memory leaks while running the following test:

*void*CallCurl() {

    CURL*hnd;

    hnd = curl_easy_init();

curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);

curl_easy_perform(hnd);

curl_easy_cleanup(hnd);

}


I track the leaks with macOS instruments, and I see that all leaks are 
from SSL (I am using the default SSL that the shipped curl uses).



What happens if you call OPENSSL_cleanup() before exit?

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


RE: Seek problem with curl_formadd with CURLFORM_STREAM

2024-01-30 Thread Jeff Mears via curl-library
> I would perhaps also add that switching to the mime API is normally not a very

> big nor complicated task.

Yeah, it was easy, and it's working for us.  =)  I guess this thread is more 
for reporting a bug and another reason to switch to curl_mime_*.

Thanks~

From: curl-library  On Behalf Of Daniel 
Stenberg via curl-library
Sent: Tuesday, January 30, 2024 12:45 AM
To: Patrick Monnerat via curl-library 
Cc: Daniel Stenberg 
Subject: Re: Seek problem with curl_formadd with CURLFORM_STREAM

On Tue, 30 Jan 2024, Patrick Monnerat via curl-library wrote: > As the formadd 
API is deprecated, this is not considered as a bug anymore > and won't be 
fixed. It is however one of the caveats that motivated the > design of the MIME
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

On Tue, 30 Jan 2024, Patrick Monnerat via curl-library wrote:



> As the formadd API is deprecated, this is not considered as a bug anymore

> and won't be fixed. It is however one of the caveats that motivated the

> design of the MIME API and I think the best way you fix your program is by

> migrating it to the latter.



I would perhaps also add that switching to the mime API is normally not a very

big nor complicated task.



--



  / daniel.haxx.se

  | Commercial curl support up to 24x7 is available!

  | Private help, bug fixes, support, ports, new features

  | 
https://urldefense.com/v3/__https://curl.se/support.html__;!!Ci6f514n9QsL8ck!gHHIBBuSEbcSTGQydoeEZIj0sIolgzqDIzmVeN8C3XMAAYmnp-iNM1pWuwrKv95_qP3Cq1GcNzwgYNWqBrPBr_5gvOWW$

--

Unsubscribe: 
https://urldefense.com/v3/__https://lists.haxx.se/mailman/listinfo/curl-library__;!!Ci6f514n9QsL8ck!gHHIBBuSEbcSTGQydoeEZIj0sIolgzqDIzmVeN8C3XMAAYmnp-iNM1pWuwrKv95_qP3Cq1GcNzwgYNWqBrPBrx1uZdfk$

Etiquette:   
https://urldefense.com/v3/__https://curl.se/mail/etiquette.html__;!!Ci6f514n9QsL8ck!gHHIBBuSEbcSTGQydoeEZIj0sIolgzqDIzmVeN8C3XMAAYmnp-iNM1pWuwrKv95_qP3Cq1GcNzwgYNWqBrPBr9vfbgJO$
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread Mos Yud via curl-library
The leaks are checked after curl_global_cleanup(). I haven't checked it yet
on release 8.5.0.

On Tue, Jan 30, 2024 at 7:18 PM Dan Fandrich via curl-library <
curl-library@lists.haxx.se> wrote:

> Is the code calling curl_global_cleanup() before checking for leaks? Does
> this happen on the latest curl releae (8.5.0)?
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html
>
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread Dan Fandrich via curl-library
Is the code calling curl_global_cleanup() before checking for leaks? Does this 
happen on the latest curl releae (8.5.0)?
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


M1 macOS | Memory leaks at SSL that is used by libcurl/8.1.2 (SecureTransport)

2024-01-30 Thread Mos Yud via curl-library
Hi,

Machine: M1 sonoma 14.1.1

At my test I am using the shipped lib of curl, and its default used SSL,
that is:
curl 8.1.2 (x86_64-apple-darwin23.0) libcurl/8.1.2 (SecureTransport)
LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1

I am getting memory leaks while running the following test:

*void* CallCurl() {

CURL *hnd;

hnd = curl_easy_init();

curl_easy_setopt(hnd, CURLOPT_URL, "https://www.google.com";);

curl_easy_perform(hnd);

curl_easy_cleanup(hnd);

}

I track the leaks with macOS instruments, and I see that all leaks are from
SSL (I am using the default SSL that the shipped curl uses).

Examples for the leaks stack frames:
1.
serialize_ECPublicKey
ECDSA_do_verify_new
ossl_ecdsa_verify
EVP_DigestVerifyFinal
tls13_server_certificate_verify_recv
tls13_handshake_perform
tls13_legacy_connect
ossl_connect_common
ssl_cf_connect
cf_setup_connect
cf_hc_connect
Curl_conn_connect
multi_runsingle
curl_multi_perform
curl_easy_perform
CallCurl()
main
start

2.
ccMallocECCryptor
CCECCryptorImportKey
ECDSA_do_verify_new
ossl_ecdsa_verify
EVP_DigestVerifyFinal
tls13_server_certificate_verify_recv
tls13_handshake_perform
tls13_legacy_connect
ossl_connect_common
ssl_cf_connect
cf_setup_connect
cf_hc_connect
Curl_conn_connect
multi_runsingle
curl_multi_perform
curl_easy_perform
CallCurl()
main
start

3.
ccMallocECCryptor
CCECCryptorImportKey
ECDSA_do_verify_new
ossl_ecdsa_verify
EVP_DigestVerifyFinal
tls13_server_certificate_verify_recv
tls13_handshake_perform
tls13_legacy_connect
ossl_connect_common
ssl_cf_connect
cf_setup_connect
cf_hc_connect
Curl_conn_connect
multi_runsingle
curl_multi_perform
curl_easy_perform
CallCurl()
main
start

Any advice?

Thx,
Moshe.
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


CVE-2023-52071 is bogus

2024-01-30 Thread Daniel Stenberg via curl-library

Hi all,

There was another bogus curl CVE filed, published today. We will try to reject 
it proper, but here is our official take on it:


 https://curl.se/docs/CVE-2023-52071.html

(this CVE was filed before we become a CNA)

--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: Seek problem with curl_formadd with CURLFORM_STREAM

2024-01-30 Thread Daniel Stenberg via curl-library

On Tue, 30 Jan 2024, Patrick Monnerat via curl-library wrote:

As the formadd API is deprecated, this is not considered as a bug anymore 
and won't be fixed. It is however one of the caveats that motivated the 
design of the MIME API and I think the best way you fix your program is by 
migrating it to the latter.


I would perhaps also add that switching to the mime API is normally not a very 
big nor complicated task.


--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html