Bug 759259 (CVE-2020-8284, CVE-2020-8285, CVE-2020-8286) – <net-misc/curl-7.74.0: Multiple vulnerabilities (CVE-2020-{8284,8285,8286})

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description John Helmert III 2020-12-09 18:05:26 UTC]

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.

[Comment 1 Anthony Basile 2020-12-09 20:40:32 UTC]

> 
> Maintainer, these are fixed in curl 7.74.0. Please bump.

Its ready and can be rapid stabilized.

[Comment 2 John Helmert III 2020-12-09 20:42:46 UTC]

(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!

[Comment 3 Sam James 2020-12-10 18:41:19 UTC]

arm64 done

[Comment 4 Rolf Eike Beer 2020-12-10 19:23:26 UTC]

hppa/sparc stable

[Comment 5 Thomas Deutschmann (RETIRED) 2020-12-10 23:46:22 UTC]

x86 stable

[Comment 6 Sam James 2020-12-13 11:17:06 UTC]

arm stable

[Comment 7 Sergei Trofimovich (RETIRED) 2020-12-13 11:51:40 UTC]

ppc/ppc64 stable

[Comment 8 Sam James 2020-12-13 23:27:05 UTC]

s390 stable

[Comment 9 Agostino Sarubbo 2020-12-17 16:44:29 UTC]

amd64 stable.

Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.

[Comment 10 Thomas Deutschmann (RETIRED) 2020-12-22 22:54:17 UTC]

New GLSA request filed.

[Comment 11 GLSAMaker/CVETool Bot 2020-12-23 20:20:36 UTC]

This issue was resolved and addressed in
 GLSA 202012-14 at https://security.gentoo.org/glsa/202012-14
by GLSA coordinator Thomas Deutschmann (whissi).