CVE-2020-8284 (https://curl.se/docs/CVE-2020-8284.html): A malicious server can use the `PASV` response to trick curl into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions. CVE-2020-8285 (https://curl.se/docs/CVE-2020-8285.html): libcurl offers a wildcard matching functionality, which allows a callback (set with `CURLOPT_CHUNK_BGN_FUNCTION`) to return information back to libcurl on how to handle a specific entry in a directory when libcurl iterates over a list of all available entries. When this callback returns `CURL_CHUNK_BGN_FUNC_SKIP`, to tell libcurl to not deal with that file, the internal function in libcurl then calls itself recursively to handle the next directory entry. If there's a sufficient amount of file entries and if the callback returns "skip" enough number of times, libcurl runs out of stack space. The exact amount will of course vary with platforms, compilers and other environmental factors. The content of the remote directory is not kept on the stack, so it seems hard for the attacker to control exactly what data that overwrites the stack - however it remains a Denial-Of-Service vector as a malicious user who controls a server that a libcurl-using application works with under these premises can trigger a crash. CVE-2020-8286 (https://curl.se/docs/CVE-2020-8286.html): libcurl offers "OCSP stapling" via the `CURLOPT_SSL_VERIFYSTATUS` option. When set, libcurl verifies the OCSP response that a server responds with as part of the TLS handshake. It then aborts the TLS negotiation if something is wrong with the response. The same feature can be enabled with `--cert-status` using the curl tool. As part of the OCSP response verification, a client should verify that the response is indeed set out for the correct certificate. This step was not performed by libcurl when built or told to use OpenSSL as TLS backend. This flaw would allow an attacker, who perhaps could have breached a TLS server, to provide a fraudulent OCSP response that would appear fine, instead of the real one. Like if the original certificate actually has been revoked. Maintainer, these are fixed in curl 7.74.0. Please bump.
> > Maintainer, these are fixed in curl 7.74.0. Please bump. Its ready and can be rapid stabilized.
(In reply to Anthony Basile from comment #1) > > > > Maintainer, these are fixed in curl 7.74.0. Please bump. > > Its ready and can be rapid stabilized. Thanks!
arm64 done
hppa/sparc stable
x86 stable
arm stable
ppc/ppc64 stable
s390 stable
amd64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
New GLSA request filed.
This issue was resolved and addressed in GLSA 202012-14 at https://security.gentoo.org/glsa/202012-14 by GLSA coordinator Thomas Deutschmann (whissi).
