Accepted curl 7.74.0-1.3+deb11u2 (source) into proposed-updates->stable-new, proposed-updates
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sun, 31 Jul 2022 17:09:17 CEST
Source: curl
Architecture: source
Version: 7.74.0-1.3+deb11u2
Distribution: bullseye-security
Urgency: high
Maintainer: Alessandro Ghedini <ghedo@debian.org>
Changed-By: Markus Koschany <apo@debian.org>
Checksums-Sha1:
20ac864b0801c66ce30421b1994c581c77251cca 2850 curl_7.74.0-1.3+deb11u2.dsc
cd7239cf9223b39ade86a14eb37fe68f5656eae9 4043409 curl_7.74.0.orig.tar.gz
1f5371da87d97afa3b1770f9ba434a4ffb5bc349 56456 curl_7.74.0-1.3+deb11u2.debian.tar.xz
84dfd36f3c7624d11cccca707ffc3f98350cc3f5 13044 curl_7.74.0-1.3+deb11u2_amd64.buildinfo
Checksums-Sha256:
3399df07e4d03f86229f9d24a1119fdd14c11651fbd48d9d5f5a111e8b4253a6 2850 curl_7.74.0-1.3+deb11u2.dsc
e56b3921eeb7a2951959c02db0912b5fcd5fdba5aca071da819e1accf338bbd7 4043409 curl_7.74.0.orig.tar.gz
dd4151f63e97989e260c60ab2bf8b2e84bd9eea73686b6b2b12ff48e967ebe8e 56456 curl_7.74.0-1.3+deb11u2.debian.tar.xz
d249d8d76dcf0ab23a1b74c5e47e05517aaf7462e6934954691a64c8677ca1e6 13044 curl_7.74.0-1.3+deb11u2_amd64.buildinfo
Changes:
curl (7.74.0-1.3+deb11u2) bullseye-security; urgency=high
.
* Non-maintainer upload.
* CVE-2021-22898:
curl suffers from an information disclosure when the `-t` command line
option, known as `CURLOPT_TELNETOPTIONS` in libcurl, is used to send
variable=content pairs to TELNET servers. Due to a 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, resulting in
potentially revealing sensitive internal information to the server using a
clear-text network protocol.
* CVE-2021-22924:
libcurl keeps previously used connections in a connection pool for
subsequenttransfers to reuse, if one of them matches the setup.Due to
errors in the logic, the config matching function did not take 'issuercert'
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 caneven vary depending on
used file systems.The comparison also didn't include the 'issuer cert'
which a transfer can setto qualify how to verify the server certificate.
* CVE-2021-22945:
When sending data to an MQTT server, libcurl could in some circumstances
erroneously keep a pointer to an already freed memory area and both use
that again in a subsequent call to send data and also free it *again*.
* CVE-2021-22946:
A user can tell curl to require a successful upgrade to TLS when speaking
to an IMAP, POP3 or FTP server (`--ssl-reqd` on the command line
or`CURLOPT_USE_SSL` set to `CURLUSESSL_CONTROL` or `CURLUSESSL_ALL`
withlibcurl). This requirement could be bypassed if the server would return
a properly crafted but perfectly legitimate response. This flaw would then
make curl silently continue its operations **withoutTLS** contrary to the
instructions and expectations, exposing possibly sensitive data in clear
text over the network.
* CVE-2021-22947:
When curl connects to an IMAP or POP3 server to retrieve data using
STARTTLS to upgrade to TLS security, the server can respond and send back
multiple responses at once that curl caches. curl would then upgrade to TLS
but not flush the in-queue of cached responses but instead continue using
and trustingthe responses it got *before* the TLS handshake as if they were
authenticated.Using this flaw, it allows a Man-In-The-Middle attacker to
first inject the fake responses, then pass-through the TLS traffic from the
legitimate server and trick curl into sending data back to the user
thinking the attacker's injected data comes from the TLS-protected server.
* CVE-2022-22576:
An improper authentication vulnerability exists in curl which might allow
reuse OAUTH2-authenticated connections without properly making sure that
the connection was authenticated with the same credentials as set for this
transfer. This affects SASL-enabled protocols: SMPTP(S), IMAP(S), POP3(S)
and LDAP(S) (openldap only).
* CVE-2022-27774:
An insufficiently protected credentials vulnerability exists in curl that
could allow an attacker to extract credentials when follows HTTP(S)
redirects is used with authentication could leak credentials to other
services that exist on different protocols or port numbers.
* CVE-2022-27775:
An information disclosure vulnerability exists in curl. By using an
IPv6 address that was in the connection pool but with a different zone id
it could reuse a connection instead.
* CVE-2022-27776:
A insufficiently protected credentials vulnerability in curl might leak
authentication or cookie header data on HTTP redirects to the same host but
another port number.
* CVE-2022-27781:
libcurl provides the `CURLOPT_CERTINFO` option to allow applications
torequest details to be returned about a server's certificate chain.Due to
an erroneous function, a malicious server could make libcurl built withNSS
get stuck in a never-ending busy-loop when trying to retrieve
thatinformation.
* CVE-2022-27782:
libcurl would reuse a previously created connection even when a TLS or
SSHrelated option had been changed that should have prohibited
reuse.libcurl keeps previously used connections in a connection pool for
subsequenttransfers to reuse if one of them matches the setup. However,
several TLS andSSH settings were left out from the configuration match
checks, making themmatch too easily.
* CVE-2022-32205:
A malicious server can serve excessive amounts of `Set-Cookie:` headers in
a HTTP response to curl and curl stores all of them. A sufficiently large
amount of (big) cookies make subsequent HTTP requests to this, or other
servers to which the cookies match, create requests that become larger than
the threshold that curl uses internally to avoid sending crazy large
requests (1048576 bytes) and instead returns an error. This denial state
might remain for as long as the same cookies are kept, match and haven't
expired. Due to cookie matching rules, a server on `foo.example.com` can
set cookies that also would match for `bar.example.com`, making it it
possible for a "sister server" to effectively cause a denial of service for
a sibling site on the same second level domain using this method.
* CVE-2022-32206:
curl supports "chained" HTTP compression algorithms, meaning that a
serverresponse can be compressed multiple times and potentially with
different algorithms. The number of acceptable "links" in this
"decompression chain" was unbounded, allowing a malicious server to insert
a virtually unlimited number of compression steps.The use of such a
decompression chain could result in a "malloc bomb", makingcurl end up
spending enormous amounts of allocated heap memory, or trying toand
returning out of memory errors.
* CVE-2022-32207:
When curl saves cookies, alt-svc and hsts data to local files, it makes the
operation atomic by finalizing the operation with a rename from a temporary
name to the final target file name.In that rename operation, it might
accidentally *widen* the permissions for the target file, leaving the
updated file accessible to more users than intended.
* CVE-2022-32208:
When curl does FTP transfers secured by krb5, it handles message
verification failures wrongly. This flaw makes it possible for a
Man-In-The-Middle attack to go unnoticed and even allows it to inject data
to the client.
Files:
afbc14b9fc183aa6b2198b4069dc3b62 2850 web optional curl_7.74.0-1.3+deb11u2.dsc
45f468aa42c4af027c4c6ddba58267f0 4043409 web optional curl_7.74.0.orig.tar.gz
7921b38559a065e7081c1d82137efb71 56456 web optional curl_7.74.0-1.3+deb11u2.debian.tar.xz
8471fc8760082eac8b2d3c0b45f8611d 13044 web optional curl_7.74.0-1.3+deb11u2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQKjBAEBCgCNFiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmLmnWhfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD
RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQPHGFwb0BkZWJp
YW4ub3JnAAoJENmtFLlRO1HkFcAP/jpNY7ilc0ArArRvPcHaLL/2KypuohtFDJN7
aWGBbVrWlYG7UD3rHU5NTDExK6pKGLe0UIytJ12G9z4ZmoGkw4NAetbHQ0Z49xuc
hTiOImGy5Z9XRpvGOdTz+8SqPdid6cQaRVtD1/HLHeIo1pxFYvQ0yMDMeYVJ2d6i
Jn6qRFefXU1JIPxNOwh/X0Y5jJmw+NrmJuPfPwT5Rp3wzzMgitF7QyhJxGGfFA5a
Fg6KJN2zZJduizJZzOfLNTo7QtRSFzBOX+EhtEBPRHs71LwcZeX8I2WSGuvnHNxa
RVNBiwfTGhc5ZjrtXYDY54pyqMY+dvL1ioLshufhy/gCsI6i/jCVqNaIrjyeituj
srpacgo+p9KzKvokkrApPCmdmTvP8O8vIBoL7iZ5lN25M3nZsDvIQcqCECh1Vudu
ZTo1EyWdwshtIugxnwcXboupPy5JfRZ7etsAnuDEiIKrdhyQ7R448z2J86FCDZUW
IqFikdf0NM+U9OnJybnALLgwEYTRZ3eLzCak4UlTMJ85PfnktqE1w44ZyuElWZEB
q5em0LvY2vtfrglCaef+OQVh+yHxUUHMrp8fKlL7xA4SNSyBeknHsSdZNp2jF+Kz
UMj9PCwT/zdVltlnRBHt9HAHJB0Xnfz22/yt+zJBPsbWXpV0nT5gMmW0LoJORcST
6s68onOA
=OoOA
-----END PGP SIGNATURE-----
Reply to: