Re: 7.78.0: configure: tweak nghttp2 library name fix

2021-07-21 Thread Daniel Stenberg via curl-library

On Wed, 21 Jul 2021, Christian Weisgerber via curl-library wrote:

Similar variable manipulation elsewhere in configure.ac uses sed, so I 
suggest to use the same idiom here:


Thanks, I made a PR out of your patch: https://github.com/curl/curl/pull/7472

--

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

7.78.0: configure: tweak nghttp2 library name fix

2021-07-21 Thread Christian Weisgerber via curl-library
This commit for curl 7.78.0...

configure: fix nghttp2 library name for static builds
https://github.com/curl/curl/commit/29c7cf79e8b44cfe98306a41a766d10e98c13d2b

... introduced a problem by assuming that LIB_H2 does not have any
leading whitespace.  At least OpenBSD's native pkg-config can produce
such whitespace, though:

$ pkg-config --libs-only-l libnghttp2
 -lnghttp2

As a result, the configure check for libnghttp2 will erroneously
fail.

Similar variable manipulation elsewhere in configure.ac uses sed,
so I suggest to use the same idiom here:

--- configure.ac.orig
+++ configure.ac
@@ -2541,7 +2541,7 @@ if test X"$want_h2" != Xno; then
 LDFLAGS="$LDFLAGS $LD_H2"
 CPPFLAGS="$CPPFLAGS $CPP_H2"
 LIBS="$LIB_H2 $LIBS"
-LIB_H2_NAME=${LIB_H2#"-l"}
+LIB_H2_NAME=`echo $LIB_H2 | $SED -e 's/-l//'`
 
 # use nghttp2_session_set_local_window_size to require nghttp2
 # >= 1.12.0

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

13.5 Export SSL session ids

2021-07-21 Thread Catalin Raceanu via curl-library

Hello,


This is an attempt to implement 13.5 Export session ids 
 feature from the 
TODO list. It only works for OpenSSL, but adding support for other 
back-ends should be rather straightforward.


See PR#7467 .

How it is supposed to work:

 * Exporting: when a new SSL session was established, a user callback
   will be executed with the serialized info of the new session. The
   relevant new symbols here are:
 o CURLOPT_SSL_SESS_FUNCTION
 o CURLOPT_SSL_SESS_DATA
 o curl_ssl_sess_callback (prototype)
 * Importing: when SSL session cache was initialized, a user callback
   will be executed to allow user code to pass serialized session info
   blobs to curl. The relevant new symbols here are:
 o CURLOPT_SSL_CACHE_FUNCTION
 o CURLOPT_SSL_CACHE_DATA
 o curl_ssl_cache_callback (prototype)


Things that probably need improving:

 * The patch is pretty big. If it is difficult to review, I guess it
   can be split in at least 2 parts: export, import. It got like this
   due to too many change attempts that could not really be isolated...
 * Naming: it might have been a better idea to use "export"/"import"
   rather than "dump"/"load", but this should be fairly quick to
   change. The same goes for any other names, so please let me know
   about any other terminology preference.
 * Some implementation decisions might not have been the right ones:
 o Dumping (export) and loading (import) work with the minimum
   amount of data: { back-end id, scheme, hostname, port,
   serialized blob, blob size }.
   Why: this seemed to be enough for the use cases here, also when
   using the same feature in other libs.
   Concerns: a sessionid loaded to cache (thus with some missing
   details) will have them filled in from the first connection that
   is trying to use it. Could that ever go wrong?
 o Memory handling, when loading sessionid-s: user code is supposed
   to allocate memory for the structures (and their members) for
   all instances that are too be loaded. Then curl code will
   release that memory after execution has returned from the
   callback. For this it required the proper release function,
   which needed to be set from the user code in the same callback.
   When not setting it, it will fallback to Curl_cfree(). Is this
   ok, or should this case always require the use of
   curl_global_init_mem(), or is there a simpler and better way
   that I've missed?
 * Documentation: I tried adding relevant comments to code, but if
   there is any other place where they need to be added please let me know.
 * Test Cases: I don't really know how a test case for this would work.
   Tests here have been based on breakpoints and log messages from curl.


Regards,

C


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

[SECURITY ADVISORY] curl: CURLOPT_SSLCERT mixup with Secure Transport

2021-07-21 Thread Daniel Stenberg via curl-library

CURLOPT_SSLCERT mixup with Secure Transport
===

Project curl Security Advisory, July 21st 2021 -
[Permalink](https://curl.se/docs/CVE-2021-22926.html)

VULNERABILITY
-

libcurl-using applications can ask for a specific client certificate to be
used in a transfer. This is done with the `CURLOPT_SSLCERT` option (`--cert`
with the command line tool).

When libcurl is built to use the macOS native TLS library Secure Transport, an
application can ask for the client certificate by name or with a file name -
using the same option. If the name exists as a file, it will be used instead
of by name.

If the appliction runs with a current working directory that is writable by
other users (like `/tmp`), a malicious user can create a file name with the
same name as the app wants to use by name, and thereby trick the application
to use the file based cert instead of the one referred to by name making
libcurl send the wrong client certificate in the TLS connection handshake.

We are not aware of any exploit of this flaw.

INFO


This flaw has existed in curl since commit
[d2fe616e7e](https://github.com/curl/curl/commit/d2fe616e7e) in libcurl
7.33.0, released on October 14, 2013.

The fixed libcurl version will now instead first check for a certificate in
the key chain using the specified name and only if one does not exist, it will
check for a file name.

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

CWE-295: Improper Certificate Validation

Severity: Medium

AFFECTED VERSIONS
-

Using libcurl on macOS built to use Secure Transport.

- Affected versions: curl 7.33.0 to and including 7.77.0
- Not affected versions: curl < 7.33.0 and curl >= 7.78.0

Also note that libcurl is used by many applications, and not always advertised
as such.

THE SOLUTION


File names used in this option must contain at least one slash.

A [fix for 
CVE-2021-22926](https://github.com/curl/curl/commit/fd9b40bf8dfd43edcbc0d254d613d95a11061c05)

RECOMMENDATIONS
--

 A - Upgrade curl to version 7.78.0

 B - Apply the patch to your local version

 C - Do now run your application in directories where other users can inject
 files.

TIMELINE


This issue was reported to the curl project on June 15, 2021.

This advisory was posted on July 21, 2021.

CREDITS
---

This issue was reported by Harry Sintonen. 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://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

[SECURITY ADVISORY] curl: TELNET stack contents disclosure again

2021-07-21 Thread Daniel Stenberg via curl-library

TELNET stack contents disclosure again
==

Project curl Security Advisory, July 21st 2021 -
[Permalink](https://curl.se/docs/CVE-2021-22925.html)

VULNERABILITY
-

curl supports the `-t` command line option, known as `CURLOPT_TELNETOPTIONS`
in libcurl. This rarely used option is used to send variable=content pairs to
TELNET servers.

Due to flaw in the option parser for sending `NEW_ENV` variables, libcurl
could be made to pass on uninitialized data from a stack based buffer to the
server. Therefore potentially revealing sensitive internal information to the
server using a clear-text network protocol.

This could happen because curl did not call and use sscanf() correctly when
parsing the string provided by the application.

The previous curl security vulnerability
[CVE-2021-22898](https://curl.se/docs/CVE-2021-22898.html) is almost identical
to this one but the fix was insufficient so this security vulnerability
remained.

We are not aware of any exploit of this flaw.

INFO


This flaw has existed in curl since commit
[a1d6ad2610](https://github.com/curl/curl/commit/a1d6ad2610) in libcurl 7.7,
released on March 22, 2001. There was a previous attempt to fix this issue in
curl 7.77.0 but it was not done proper.

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

CWE-457: Use of Uninitialized Variable

Severity: Medium

AFFECTED VERSIONS
-

- Affected versions: curl 7.7 to and including 7.77.0
- Not affected versions: curl < 7.7 and curl >= 7.78.0

Also note that libcurl is used by many applications, and not always advertised
as such.

THE SOLUTION


Use sscanf() properly and only use properly filled-in buffers.

A [fix for 
CVE-2021-22925](https://github.com/curl/curl/commit/894f6ec730597eb243618d33cc84d71add8d6a8a)

RECOMMENDATIONS
--

 A - Upgrade curl to version 7.78.0

 B - Apply the patch to your local version

 C - Avoid using `CURLOPT_TELNETOPTIONS`

TIMELINE


This issue was reported to the curl project on June 11, 2021.

This advisory was posted on July 21, 2021.

CREDITS
---

This issue was reported and patched by Red Hat Product Security.

Thanks a lot!

--

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

[SECURITY ADVISORY] curl: Bad connection reuse due to flawed path name checks

2021-07-21 Thread Daniel Stenberg via curl-library

Bad connection reuse due to flawed path name checks
===

Project curl Security Advisory, July 21st 2021 -
[Permalink](https://curl.se/docs/CVE-2021-22924.html)

VULNERABILITY
-

libcurl keeps previously used connections in a connection pool for subsequent
transfers to reuse, if one of them matches the setup.

Due to errors in the logic, the config matching function did not take 'issuer
cert' into account and it compared the involved paths *case insensitively*,
which could lead to libcurl reusing wrong connections.

File paths are, or can be, case sensitive on many systems but not all, and can
even vary depending on used file systems.

The comparison also didn't include the 'issuer cert' which a transfer can set
to qualify how to verify the server certificate.

We are not aware of any exploit of this flaw.

INFO


This flaw has existed in curl since commit
[89721ff04af70f](https://github.com/curl/curl/commit/89721ff04af70f) in
libcurl 7.10.4, released on April 2, 2003.

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

CWE-295: Improper Certificate Validation

Severity: Medium

AFFECTED VERSIONS
-

- Affected versions: curl 7.10.4 to and including 7.77.0
- Not affected versions: curl < 7.10.4 and curl >= 7.78.0

Also note that libcurl is used by many applications, and not always advertised
as such.

THE SOLUTION


The SSL configs are compared appropriately.

A [fix for 
CVE-2021-22924](https://github.com/curl/curl/commit/5ea3145850ebff1dc2b13d17440300a01ca38161)

RECOMMENDATIONS
--

 A - Upgrade curl to version 7.78.0

 B - Apply the patch to your local version

TIMELINE


This issue was reported to the curl project on June 11, 2021.

This advisory was posted on July 21, 2021.

CREDITS
---

This issue was reported by Harry Sintonen. 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://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

[SECURITY ADVISORY] curl: Metalink download sends credentials

2021-07-21 Thread Daniel Stenberg via curl-library

Metalink download sends credentials
===

Project curl Security Advisory, July 21th 2021 -
[Permalink](https://curl.se/docs/CVE-2021-22923.html)

VULNERABILITY
-

When curl is instructed to get content using the metalink feature, and a user
name and password are used to download the metalink XML file, those same
credentials are then subsequently passed on to each of the servers from which
curl will download or try to download the contents from. Often contrary to the
user's expectations and intentions and without telling the user it happened.

We are not aware of any exploit of this flaw.

INFO


This flaw exists only in the curl tool. libcurl is not affected.

This flaw has existed in curl since commit
[b5fdbe848bc3d](https://github.com/curl/curl/commit/b5fdbe848bc3d) in curl
7.27.0, released on July 27, 2012.

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

CWE-522: Insufficiently Protected Credentials

Severity: Medium

AFFECTED VERSIONS
-

- Affected versions: curl 7.27.0 to and including 7.77.0
- Not affected versions: curl < 7.27.0 and curl >= 7.78.0

THE SOLUTION


curl has completely removed the metalink feature as of 7.78.0. No fix for this
flaw will be produced by the curl project.

The fix for earlier versions is to rebuild curl with the metalink support
switched off!

RECOMMENDATIONS
--

 A - Upgrade curl to version 7.78.0

 B - Make sure you do not use metalink with curl

 C - Disable metalink in your build

TIMELINE


This issue was reported to the curl project on May 30, 2021.

This advisory was posted on Jul 21, 2021.

CREDITS
---

This issue was reported by Harry Sintonen. 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://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

[SECURITY ADVISORY] curl: Wrong content via metalink not discarded

2021-07-21 Thread Daniel Stenberg via curl-library

Wrong content via metalink not discarded


Project curl Security Advisory, July 21th 2021 -
[Permalink](https://curl.se/docs/CVE-2021-22922.html)

VULNERABILITY
-

When curl is instructed to download content using the metalink feature, the
contents is verified against a hash provided in the metalink XML file.

The metalink XML file points out to the client how to get the same content
from a set of different URLs, potentially hosted by different servers and the
client can then download the file from one or several of them. In a serial or
parallel manner.

If one of the servers hosting the contents has been breached and the contents
of the specific file on that server is replaced with a modified payload, curl
should detect this when the hash of the file mismatches after a completed
download. It should remove the contents and instead try getting the contents
from another URL. This is not done, and instead such a hash mismatch is only
mentioned in text and the potentially malicious content is kept in the file on
disk.

There's a risk the user doesn't notice the message and instead assumes the
file is fine.

We are not aware of any exploit of this flaw.

INFO


This flaw exists only in the curl tool. libcurl is not affected.

This flaw has existed in curl since commit
[b5fdbe848bc3d](https://github.com/curl/curl/commit/b5fdbe848bc3d) in curl
7.27.0, released on July 27, 2012.

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

CWE-20: Improper Input Validation

Severity: Medium

AFFECTED VERSIONS
-

- Affected versions: curl 7.27.0 to and including 7.77.0
- Not affected versions: curl < 7.27.0 and curl >= 7.78.0

THE SOLUTION


curl has completely removed the metalink feature as of 7.78.0. No fix for this
flaw will be produced by the curl project.

The fix for earlier versions is to rebuild curl with the metalink support
switched off!

RECOMMENDATIONS
--

 A - Upgrade curl to version 7.78.0

 B - Make sure you do not use metalink with curl

 C - Disable metalink in your build

TIMELINE


This issue was reported to the curl project on May 30, 2021.

This advisory was posted on Jul 21, 2021.

CREDITS
---

This issue was reported by Harry Sintonen. 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://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

[RELEASE] curl 7.78.0

2021-07-21 Thread Daniel Stenberg via curl-library

Hi friends!

I'm happy to announce another curl release. This time we bring a few 
changes and no less than FIVE security advisories (see subsequent mails 
about the specifics). Get curl as always from:


  https://curl.se/

curl and libcurl 7.78.0

 Public curl releases: 201
 Command line options: 242
 curl_easy_setopt() options:   290
 Public functions in libcurl:  85
 Contributors: 2459

This release includes the following changes:

 o curl_url_set: reject spaces in URLs w/o CURLU_ALLOW_SPACE [118]
 o CURLE_SETOPT_OPTION_SYNTAX: new error name for wrong setopt syntax [40]
 o hostip: make 'localhost' return fixed values [16]
 o mbedtls: add support for cert and key blob options [11]
 o metalink: remove all support for it [54]
 o mqtt: add support for username and password [91]

This release includes the following bugfixes:

 o --socks4[a]: clarify where the host name is resolved [107]
 o ares: always store IPv6 addresses first [20]
 o asyn-ares: remove check for 'data' in Curl_resolver_cancel [89]
 o bearssl: explicitly initialize all fields of Curl_ssl [1]
 o bearssl: remove incorrect const on variable that is modified [1]
 o build: fix compiler warnings when CURL_DISABLE_VERBOSE_STRINGS [155]
 o c-hyper: abort CONNECT response reading early on non 2xx responses [75]
 o c-hyper: add support for transfer-encoding in the request [121]
 o c-hyper: bail on too long response headers [115]
 o c-hyper: clear NTLM auth buffer when request is issued [23]
 o c-hyper: convert HYPERE_INVALID_PEER_MESSAGE to CURLE_UNSUPPORTED_PROTOCOL 
[21]
 o c-hyper: fix NTLM on closed connection tested with test159 [4]
 o c-hyper: fix the uploaded field in progress callbacks [78]
 o c-hyper: handle NULL from hyper_buf_copy() [19]
 o c-hyper: support CURLINFO_STARTTRANSFER_TIME [29]
 o c-hyper: support CURLOPT_HEADER [32]
 o ccsidcurl: fix the compile errors [27]
 o CI/cirrus: install impacket from PyPI instead of FreeBSD packages [166]
 o CI: add bearssl build [1]
 o CI: add Circle CI [92]
 o CI: add jobs using Zuul [86]
 o CI: delete --enable-hsts option (it is the default now) [2]
 o CI: remove travis details [144]
 o cleanup: spell DoH with a lowercase o [172]
 o cmake: add CURL_DISABLE_NTLM option [44]
 o cmake: avoid leaking absolute paths into exported config [3]
 o cmake: fix IoctlSocket FIONBIO check [156]
 o cmake: fix support for UnixSockets feature on Win32 [104]
 o cmake: remove libssh2 feature checks [122]
 o cmake: try well-known send/recv signature for Apple [12]
 o configure.ac: make non-executable [109]
 o configure/cmake: remove checks for many unused functions [95]
 o configure: add --disable-ntlm option [45]
 o configure: disable RTSP when hyper is selected [68]
 o configure: do not strip out debug flags [110]
 o configure: fix nghttp2 library name for static builds [157]
 o configure: inhibit the implicit-fallthrough warning on gcc-12 [106]
 o configure: rename get-easy-option configure option to get-easy-options [81]
 o conn_shutdown: if closed during CONNECT cleanup properly [59]
 o conncache: lowercase the hash key for better match [5]
 o cookies: track expiration in jar to optimize removals [25]
 o copyright: add boiler-plate headers to CI config files [143]
 o crustls: bump crustls version and use new URL [119]
 o curl.h:  is supported by VxWorks7 [102]
 o curl.h: include sys/select.h for NuttX RTOS [100]
 o curl: ignore blank --output-dir [57]
 o curl_endian: remove the unused Curl_write64_le function [85]
 o curl_multibyte: Remove local encoding fallbacks [58]
 o Curl_ntlm_core_mk_nt_hash: fix OOM in error path [8]
 o Curl_ssl_getsessionid: fail if no session cache exists [14]
 o CURLOPT_WRITEFUNCTION.3: minor update of the example [80]
 o docs/BINDINGS: fix outdated links [116]
 o docs/examples: use curl_multi_poll() in multi examples [152]
 o docs/INSTALL: remove mentions of configure --with-darwin-ssl [55]
 o docs: document missing arguments to commands [160]
 o docs: fix inconsistencies in EGDSOCKET documentation [159]
 o docs: fix incorrect argument name reference [161]
 o docs: Fix typos [146]
 o docs: make docs for --etag-save match the program behaviour [169]
 o docs: use --max-redirs instead of --max-redir [28]
 o doh: (void)-prefix call to curl_easy_setopt
 o doh: fix wrong DEBUGASSERT for doh private_data [62]
 o easy: during upkeep, attach Curl_easy to connections in the cache [171]
 o examples/multi-single: fix scan-build warning [150]
 o examples: length-limit two sscanf() uses of %s [96]
 o examples: safer and more proper read callback logic [127]
 o filecheck: quietly remove test-place/*~ [39]
 o formdata: avoid "Argument cannot be negative" warning [131]
 o formdata: correct typecast in curl_mime_data call [137]
 o GHA: add a linux-hyper job [52]
 o GHA: add several libcurl tests to the hyper job
 o GHA: run the newly fixed tests with hyper [36]
 o github: timeout jobs on macOS after 90 minutes [42]
 o glob: pass an 'int' as len when using printf's %*s