SB2022041343 - .NET Core on Red Hat Enterprise Linux update for rh-dotnet31-curl
Published: April 13, 2022
Breakdown by Severity
- Low
- Medium
- High
- Critical
Description
This security bulletin contains information about 4 secuirty vulnerabilities.
1) Information disclosure (CVE-ID: CVE-2021-22876)
The vulnerability allows a remote attacker to gain access to potentially sensitive information.
The vulnerability exists due to libcurl does not strip off user credentials from the URL when automatically populating the Referer:
HTTP request header field in outgoing HTTP requests and therefore
risks leaking sensitive data to the server that is the target of the
second HTTP request.
2) Improper Certificate Validation (CVE-ID: CVE-2021-22924)
The vulnerability allows a remote attacker to compromise the target system.
The vulnerability exists due to errors in the logic when the config matching function does not take "issuer cert" into account and it compares the involved paths case insensitively. A remote attacker can gain access to sensitive information on the system.
3) Cleartext transmission of sensitive information (CVE-ID: CVE-2021-22946)
The vulnerability allows a remote attacker to gain access to sensitive information.
The vulnerability exists due to an error, related to incorrect enforcement of the --ssl-reqd option on the command line or CURLOPT_USE_SSL setting set to CURLUSESSL_CONTROL or CURLUSESSL_ALL with libcurl. A remote attacker with control over the IMAP, POP3 or FTP server can send a specially crafted but perfectly legitimate response to the libcurl client and force it silently to continue its operations without TLS encryption and transmit data in clear text over the network.
4) Insufficient verification of data authenticity (CVE-ID: CVE-2021-22947)
The vulnerability allows a remote attacker to perform MitM attack.
The vulnerability exists in the way libcurl handles the STARTTLS negotiation process. When curl connects to an IMAP, POP3, SMTP or FTP server to exchange data securely using STARTTLS to upgrade the connection to TLS level, the server can still respond and send back multiple responses before the TLS upgrade. Such multiple "pipelined" responses are cached by curl. curl would then upgrade to TLS but not flush the in-queue of cached responses and instead use and trust the 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.
Over POP3 and IMAP an attacker can inject fake response data.
Remediation
Install update from vendor's website.