Page 5 of 92 results (0.012 seconds)

CVSS: 4.3EPSS: 0%CPEs: 40EXPL: 0

The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. This issue affects OpenSSL 1.0.2 which is out of support and no longer receiving public updates. • https://lists.debian.org/debian-lts-announce/2020/09/msg00016.html https://security.gentoo.org/glsa/202210-02 https://security.netapp.com/advisory/ntap-20200911-0004 https://usn.ubuntu.com/4504-1 https://www.openssl.org/news/secadv/20200909.txt https://www.oracle.com//security-alerts/cpujul2021.html https://www.oracle.com/security-alerts/cpuApr2021.html https://www.oracle.com/security-alerts/cpuapr2022.html https://www.oracle.com/security-alerts/cpujan2021.html https://www.o • CWE-203: Observable Discrepancy •

CVSS: 5.3EPSS: 0%CPEs: 7EXPL: 0

An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because the hostname check operates on uninitialized memory. The outcome is that a valid certificate is never accepted (only a malformed certificate may be accepted). Se detectó un problema en openfortivpn versión 1.11.0, cuando se usaba con OpenSSL versiones 1.0.2 o posteriores, en el archivo tunnel.c, maneja inapropiadamente la comprobación del certificado porque la verificación del nombre de host funciona en la memoria no inicializada. El resultado es que un certificado válido nunca es aceptado (solo puede ser aceptado un certificado malformado). • http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00009.html http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00011.html https://github.com/adrienverge/openfortivpn/commit/9eee997d599a89492281fc7ffdd79d88cd61afc3 https://github.com/adrienverge/openfortivpn/commit/cd9368c6a1b4ef91d77bb3fdbe2e5bc34aa6f4c4 https://github.com/adrienverge/openfortivpn/issues/536 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CKNKSGBVYGRRVRLFEFBEKUEJYJR5LWOF https://lists.fedoraproject.org/archives/l • CWE-295: Improper Certificate Validation CWE-908: Use of Uninitialized Resource •

CVSS: 5.3EPSS: 0%CPEs: 7EXPL: 0

An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because an X509_check_host negative error code is interpreted as a successful return value. Se detectó un problema en openfortivpn versión 1.11.0, cuando se usaba con OpenSSL versiones 1.0.2 o posteriores, el archivo tunnel.c maneja inapropiadamente la comprobación del certificado porque un código de error negativo de X509_check_host se interpreta como un valor de retorno exitoso. • http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00009.html http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00011.html https://github.com/adrienverge/openfortivpn/commit/60660e00b80bad0fadcf39aee86f6f8756c94f91 https://github.com/adrienverge/openfortivpn/commit/cd9368c6a1b4ef91d77bb3fdbe2e5bc34aa6f4c4 https://github.com/adrienverge/openfortivpn/issues/536 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CKNKSGBVYGRRVRLFEFBEKUEJYJR5LWOF https://lists.fedoraproject.org/archives/l • CWE-295: Improper Certificate Validation •

CVSS: 5.3EPSS: 0%CPEs: 18EXPL: 0

There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. • http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00030.html http://packetstormsecurity.com/files/155754/Slackware-Security-Advisory-openssl-Updates.html https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=419102400a2811582a7a3d4a4e317d72e5ce0a8f https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=f1c5eea8a817075d31e43f5876993c6710238c98 https://lists.debian.org/debian-lts-announce/2022/03/msg00023.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/messag • CWE-190: Integer Overflow or Wraparound •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. • http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00054.html http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00072.html http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00012.html http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00016.html http://packetstormsecurity.com/files/154467/Slackware-Security-Advisory-openssl-Updates.html https://arxiv.org/abs/1909.01785 https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=21c856b75d81eff61aa63b4f036b • CWE-602: Client-Side Enforcement of Server-Side Security •