CVSS: 7.4EPSS: 0%CPEs: 4EXPL: 1CVE-2021-32066 – ruby: StartTLS stripping vulnerability in Net::IMAP
https://notcve.org/view.php?id=CVE-2021-32066
An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Net::IMAP does not raise an exception when StartTLS fails with an an unknown response, which might allow man-in-the-middle attackers to bypass the TLS protections by leveraging a network position between the client and the registry to block the StartTLS command, aka a "StartTLS stripping attack." Se ha detectado un problema en Ruby versiones hasta 2.6.7, versiones 2.7.x hasta 2.7.3, y versiones 3.x hasta 3.0.1. Net::IMAP no lanza una excepción cuando StartTLS falla con una respuesta desconocida, lo que podría permitir a atacantes tipo man-in-the-middle omitir las protecciones TLS, al aprovechar una posición de red entre el cliente y el registro para bloquear el comando StartTLS, también se conoce como "StartTLS stripping attack" Ruby's Net::IMAP module did not raise an exception when receiving an unexpected response to the STARTTLS command and the connection was not upgraded to use TLS. A man-in-the-middle attacker could use this flaw to prevent Ruby applications using Net::IMAP to enable TLS encryption for a connection to an IMAP server and subsequently eavesdrop on or modify data sent over the plain text connection. • https://github.com/ruby/ruby/commit/a21a3b7d23704a01d34bd79d09dc37897e00922a https://hackerone.com/reports/1178562 https://lists.debian.org/debian-lts-announce/2021/10/msg00009.html https://lists.debian.org/debian-lts-announce/2023/04/msg00033.html https://security.gentoo.org/glsa/202401-27 https://security.netapp.com/advisory/ntap-20210902-0004 https://www.oracle.com/security-alerts/cpuapr2022.html https://www.ruby-lang.org/en/news/2021/07/07/starttls-stripping-in-net-imap https://acces • CWE-319: Cleartext Transmission of Sensitive Information CWE-755: Improper Handling of Exceptional Conditions •
CVSS: 5.8EPSS: 1%CPEs: 6EXPL: 1CVE-2021-31810 – ruby: FTP PASV command response can cause Net::FTP to connect to arbitrary host
https://notcve.org/view.php?id=CVE-2021-31810
An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. A malicious FTP server can use the PASV response to trick Net::FTP into connecting back to a given IP address and port. This potentially makes curl extract information about services that are otherwise private and not disclosed (e.g., the attacker can conduct port scans and service banner extractions). Se ha detectado un problema en Ruby versiones hasta 2.6.7, versiones 2.7.x hasta 2.7.3, y versiones 3.x hasta 3.0.1. Un servidor FTP malicioso puede usar la respuesta PASV para engañar a la función Net::FTP para que se conecte de nuevo a una dirección IP y un puerto determinados. • https://hackerone.com/reports/1145454 https://lists.debian.org/debian-lts-announce/2021/10/msg00009.html https://lists.debian.org/debian-lts-announce/2023/04/msg00033.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MWXHK5UUHVSHF7HTHMX6JY3WXDVNIHSL https://security.gentoo.org/glsa/202401-27 https://security.netapp.com/advisory/ntap-20210917-0001 https://www.oracle.com/security-alerts/cpuapr2022.html https://www.ruby-lang.org/en/news/2021/07/07/ • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •
CVSS: 5.9EPSS: 1%CPEs: 28EXPL: 0CVE-2021-21409 – Possible request smuggling in HTTP/2 due missing validation of content-length
https://notcve.org/view.php?id=CVE-2021-21409
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. • https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21295 https://github.com/netty/netty/commit/b0fa4d5aab4215f3c22ce6123dd8dd5f38dc0432 https://github.com/netty/netty/security/advisories/GHSA-f256-j965-7f32 https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj https://lists.apache.org/thread.html/r0b09f3e31e004fe583f677f7afa46bd30110904576c13c5ac818ac2c%40%3Cissues.flink.apache.org%3E https://lists.apache.org/thread.html/r0ca82fec33334e571fe5b388272260778883e307e15415d7b1443de2%40%3Cissues.zookeeper.apache.org%3E https:& • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 5.9EPSS: 0%CPEs: 205EXPL: 0CVE-2021-3449 – NULL pointer deref in signature_algorithms processing
https://notcve.org/view.php?id=CVE-2021-3449
An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. • http://www.openwall.com/lists/oss-security/2021/03/27/1 http://www.openwall.com/lists/oss-security/2021/03/27/2 http://www.openwall.com/lists/oss-security/2021/03/28/3 http://www.openwall.com/lists/oss-security/2021/03/28/4 https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://cert-portal.siemens.com/productcert/pdf/ssa-772220.pdf https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=fb9fa6b51defd48157eeb207f52181f735d96148 https://kb.pulse • CWE-476: NULL Pointer Dereference •
CVSS: 7.4EPSS: 0%CPEs: 56EXPL: 0CVE-2021-3450 – CA certificate check bypass with X509_V_FLAG_X509_STRICT
https://notcve.org/view.php?id=CVE-2021-3450
The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. • http://www.openwall.com/lists/oss-security/2021/03/27/1 http://www.openwall.com/lists/oss-security/2021/03/27/2 http://www.openwall.com/lists/oss-security/2021/03/28/3 http://www.openwall.com/lists/oss-security/2021/03/28/4 https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=2a40b7bc7b94dd7de897a74571e7024f0cf0d63b https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44845 https://kc.mc • CWE-295: Improper Certificate Validation •