Search
Total
9 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-23839 | 3 Openssl, Oracle, Siemens | 8 Openssl, Business Intelligence, Enterprise Manager For Storage Management and 5 more | 2023-08-08 | 4.3 MEDIUM | 3.7 LOW |
| OpenSSL 1.0.2 supports SSLv2. If a client attempts to negotiate SSLv2 with a server that is configured to support both SSLv2 and more recent SSL and TLS versions then a check is made for a version rollback attack when unpadding an RSA signature. Clients that support SSL or TLS versions greater than SSLv2 are supposed to use a special form of padding. A server that supports greater than SSLv2 is supposed to reject connection attempts from a client where this special form of padding is present, because this indicates that a version rollback has occurred (i.e. both client and server support greater than SSLv2, and yet this is the version that is being requested). The implementation of this padding check inverted the logic so that the connection attempt is accepted if the padding is present, and rejected if it is absent. This means that such as server will accept a connection if a version rollback attack has occurred. Further the server will erroneously reject a connection if a normal SSLv2 connection attempt is made. Only OpenSSL 1.0.2 servers from version 1.0.2s to 1.0.2x are affected by this issue. In order to be vulnerable a 1.0.2 server must: 1) have configured SSLv2 support at compile time (this is off by default), 2) have configured SSLv2 support at runtime (this is off by default), 3) have configured SSLv2 ciphersuites (these are not in the default ciphersuite list) OpenSSL 1.1.1 does not have SSLv2 support and therefore is not vulnerable to this issue. The underlying error is in the implementation of the RSA_padding_check_SSLv23() function. This also affects the RSA_SSLV23_PADDING padding mode used by various other functions. Although 1.1.1 does not support SSLv2 the RSA_padding_check_SSLv23() function still exists, as does the RSA_SSLV23_PADDING padding mode. Applications that directly call that function or use that padding mode will encounter this issue. However since there is no support for the SSLv2 protocol in 1.1.1 this is considered a bug and not a security issue in that version. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.0.2y (Affected 1.0.2s-1.0.2x). | |||||
| CVE-2021-45486 | 1 Linux | 1 Linux Kernel | 2022-07-25 | 2.7 LOW | 3.5 LOW |
| In the IPv4 implementation in the Linux kernel before 5.12.4, net/ipv4/route.c has an information leak because the hash table is very small. | |||||
| CVE-2020-24587 | 6 Arista, Cisco, Debian and 3 more | 332 C-100, C-100 Firmware, C-110 and 329 more | 2022-07-12 | 1.8 LOW | 2.6 LOW |
| The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that all fragments of a frame are encrypted under the same key. An adversary can abuse this to decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed. | |||||
| CVE-2020-24588 | 4 Debian, Ieee, Linux and 1 more | 11 Debian Linux, Ieee 802.11, Mac80211 and 8 more | 2022-07-12 | 2.9 LOW | 3.5 LOW |
| The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that the A-MSDU flag in the plaintext QoS header field is authenticated. Against devices that support receiving non-SSP A-MSDU frames (which is mandatory as part of 802.11n), an adversary can abuse this to inject arbitrary network packets. | |||||
| CVE-2020-14264 | 1 Hcltech | 1 Traveler Companion | 2021-10-28 | 2.1 LOW | 3.9 LOW |
| "HCL Traveler Companion is vulnerable to an iOS weak cryptographic process vulnerability via the included MobileIron AppConnect SDK" | |||||
| CVE-2019-1563 | 1 Openssl | 1 Openssl | 2021-07-31 | 4.3 MEDIUM | 3.7 LOW |
| In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s). | |||||
| CVE-2020-23250 | 1 Gigamon | 1 Gigavue-os | 2021-01-08 | 2.1 LOW | 2.3 LOW |
| GigaVUE-OS (GVOS) 5.4 - 5.9 uses a weak algorithm for a hash stored in internal database. | |||||
| CVE-2020-8912 | 1 Amazon | 1 Aws S3 Crypto Sdk | 2020-08-17 | 2.1 LOW | 2.5 LOW |
| A vulnerability in the in-band key negotiation exists in the AWS S3 Crypto SDK for GoLang versions prior to V2. An attacker with write access to the targeted bucket can change the encryption algorithm of an object in the bucket, which can then allow them to change AES-GCM to AES-CTR. Using this in combination with a decryption oracle can reveal the authentication key used by AES-GCM as decrypting the GMAC tag leaves the authentication key recoverable as an algebraic equation. It is recommended to update your SDK to V2 or later, and re-encrypt your files. | |||||
| CVE-2019-3700 | 1 Suse | 1 Yast2-security | 2020-02-05 | 2.1 LOW | 3.3 LOW |
| yast2-security didn't use secure defaults to protect passwords. This became a problem on 2019-10-07 when configuration files that set secure settings were moved to a different location. As of the 20191022 snapshot the insecure default settings were used until yast2-security switched to stronger defaults in 4.2.6 and used the new configuration file locations. Password created during this time used DES password encryption and are not properly protected against attackers that are able to access the password hashes. | |||||