ID CVE-2021-23839
Summary 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).
References
Vulnerable Configurations
  • cpe:2.3:a:openssl:openssl:1.0.2s:*:*:*:*:*:*:*
    cpe:2.3:a:openssl:openssl:1.0.2s:*:*:*:*:*:*:*
  • cpe:2.3:a:openssl:openssl:1.0.2t:*:*:*:*:*:*:*
    cpe:2.3:a:openssl:openssl:1.0.2t:*:*:*:*:*:*:*
  • cpe:2.3:a:openssl:openssl:1.0.2u:*:*:*:*:*:*:*
    cpe:2.3:a:openssl:openssl:1.0.2u:*:*:*:*:*:*:*
  • cpe:2.3:a:openssl:openssl:1.0.2v:*:*:*:*:*:*:*
    cpe:2.3:a:openssl:openssl:1.0.2v:*:*:*:*:*:*:*
  • cpe:2.3:a:openssl:openssl:1.0.2w:*:*:*:*:*:*:*
    cpe:2.3:a:openssl:openssl:1.0.2w:*:*:*:*:*:*:*
  • cpe:2.3:a:openssl:openssl:1.0.2x:*:*:*:*:*:*:*
    cpe:2.3:a:openssl:openssl:1.0.2x:*:*:*:*:*:*:*
  • cpe:2.3:a:oracle:business_intelligence:12.2.1.3.0:*:*:*:enterprise:*:*:*
    cpe:2.3:a:oracle:business_intelligence:12.2.1.3.0:*:*:*:enterprise:*:*:*
  • cpe:2.3:a:oracle:jd_edwards_world_security:a9.4:*:*:*:*:*:*:*
    cpe:2.3:a:oracle:jd_edwards_world_security:a9.4:*:*:*:*:*:*:*
  • cpe:2.3:a:oracle:business_intelligence:12.2.1.4.0:*:*:*:enterprise:*:*:*
    cpe:2.3:a:oracle:business_intelligence:12.2.1.4.0:*:*:*:enterprise:*:*:*
  • cpe:2.3:a:oracle:business_intelligence:5.5.0.0.0:*:*:*:enterprise:*:*:*
    cpe:2.3:a:oracle:business_intelligence:5.5.0.0.0:*:*:*:enterprise:*:*:*
  • cpe:2.3:a:oracle:enterprise_manager_for_storage_management:13.4.0.0:*:*:*:*:*:*:*
    cpe:2.3:a:oracle:enterprise_manager_for_storage_management:13.4.0.0:*:*:*:*:*:*:*
  • cpe:2.3:a:oracle:enterprise_manager_ops_center:12.4.0.0:*:*:*:*:*:*:*
    cpe:2.3:a:oracle:enterprise_manager_ops_center:12.4.0.0:*:*:*:*:*:*:*
  • cpe:2.3:a:oracle:zfs_storage_appliance_kit:8.8:*:*:*:*:*:*:*
    cpe:2.3:a:oracle:zfs_storage_appliance_kit:8.8:*:*:*:*:*:*:*
  • cpe:2.3:a:oracle:graalvm:19.3.5:*:*:*:enterprise:*:*:*
    cpe:2.3:a:oracle:graalvm:19.3.5:*:*:*:enterprise:*:*:*
  • cpe:2.3:a:oracle:graalvm:20.3.1.2:*:*:*:community:*:*:*
    cpe:2.3:a:oracle:graalvm:20.3.1.2:*:*:*:community:*:*:*
  • cpe:2.3:a:oracle:graalvm:21.0.0.2:*:*:*:community:*:*:*
    cpe:2.3:a:oracle:graalvm:21.0.0.2:*:*:*:community:*:*:*
  • cpe:2.3:a:oracle:business_intelligence:5.9.0.0.0:*:*:*:enterprise:*:*:*
    cpe:2.3:a:oracle:business_intelligence:5.9.0.0.0:*:*:*:enterprise:*:*:*
  • cpe:2.3:a:siemens:sinec_ins:1.0:sp1:*:*:*:*:*:*
    cpe:2.3:a:siemens:sinec_ins:1.0:sp1:*:*:*:*:*:*
  • cpe:2.3:a:siemens:sinec_ins:-:*:*:*:*:*:*:*
    cpe:2.3:a:siemens:sinec_ins:-:*:*:*:*:*:*:*
  • cpe:2.3:a:siemens:sinec_ins:1.0:-:*:*:*:*:*:*
    cpe:2.3:a:siemens:sinec_ins:1.0:-:*:*:*:*:*:*
CVSS
Base: 4.3 (as of 21-06-2024 - 19:15)
Impact:
Exploitability:
CWE CWE-327
CAPEC
  • Signature Spoof
    An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
  • Rooting SIM Cards
    SIM cards are the de facto trust anchor of mobile devices worldwide. The cards protect the mobile identity of subscribers, associate devices with phone numbers, and increasingly store payment credentials, for example in NFC-enabled phones with mobile wallets. This attack leverages over-the-air (OTA) updates deployed via cryptographically-secured SMS messages to deliver executable code to the SIM. By cracking the DES key, an attacker can send properly signed binary SMS messages to a device, which are treated as Java applets and are executed on the SIM. These applets are allowed to send SMS, change voicemail numbers, and query the phone location, among many other predefined functions. These capabilities alone provide plenty of potential for abuse.
  • Cryptanalysis
    Cryptanalysis is a process of finding weaknesses in cryptographic algorithms and using these weaknesses to decipher the ciphertext without knowing the secret key (instance deduction). Sometimes the weakness is not in the cryptographic algorithm itself, but rather in how it is applied that makes cryptanalysis successful. An attacker may have other goals as well, such as: Total Break (finding the secret key), Global Deduction (finding a functionally equivalent algorithm for encryption and decryption that does not require knowledge of the secret key), Information Deduction (gaining some information about plaintexts or ciphertexts that was not previously known) and Distinguishing Algorithm (the attacker has the ability to distinguish the output of the encryption (ciphertext) from a random permutation of bits).
  • Creating a Rogue Certification Authority Certificate
    An adversary exploits a weakness in the MD5 hash algorithm (weak collision resistance) to generate a certificate signing request (CSR) that contains collision blocks in the "to be signed" part. The adversary specially crafts two different, but valid X.509 certificates that when hashed with the MD5 algorithm would yield the same value. The adversary then sends the CSR for one of the certificates to the Certification Authority which uses the MD5 hashing algorithm. That request is completely valid and the Certificate Authority issues an X.509 certificate to the adversary which is signed with its private key. An adversary then takes that signed blob and inserts it into another X.509 certificate that the attacker generated. Due to the MD5 collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority. To make the attack more interesting, the second certificate could be not just a regular certificate, but rather itself a signing certificate. Thus the adversary is able to start their own Certification Authority that is anchored in its root of trust in the legitimate Certification Authority that has signed the attackers' first X.509 certificate. If the original Certificate Authority was accepted by default by browsers, so will now the Certificate Authority set up by the adversary and of course any certificates that it signs. So the adversary is now able to generate any SSL certificates to impersonate any web server, and the user's browser will not issue any warning to the victim. This can be used to compromise HTTPS communications and other types of systems where PKI and X.509 certificates may be used (e.g., VPN, IPSec).
  • Signature Spoofing by Improper Validation
    An attacker exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.
  • Encryption Brute Forcing
    An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.
  • Cryptanalysis of Cellular Encryption
    The use of cryptanalytic techniques to derive cryptographic keys or otherwise effectively defeat cellular encryption to reveal traffic content. Some cellular encryption algorithms such as A5/1 and A5/2 (specified for GSM use) are known to be vulnerable to such attacks and commercial tools are available to execute these attacks and decrypt mobile phone conversations in real-time. Newer encryption algorithms in use by UMTS and LTE are stronger and currently believed to be less vulnerable to these types of attacks. Note, however, that an attacker with a Cellular Rogue Base Station can force the use of weak cellular encryption even by newer mobile devices.
Access
VectorComplexityAuthentication
NETWORK MEDIUM NONE
Impact
ConfidentialityIntegrityAvailability
NONE PARTIAL NONE
cvss-vector via4 AV:N/AC:M/Au:N/C:N/I:P/A:N
Last major update 21-06-2024 - 19:15
Published 16-02-2021 - 17:15
Last modified 21-06-2024 - 19:15
Back to Top